The GitLab CI/CD Catalog, part of the DevSecOps platform, allows users to discover, reuse, and contribute CI/CD components to make software development more efficient and productive. Recently, we hosted a CI/CD Catalog webinar that surfaced a host of helpful questions. This FAQ features some of those questions (and answers) and highlights the CI/CD Catalog's capabilities as well as best practices for using it in your environment.

When will the CI catalog components and inputs be available on Gitlab.com?

The CI catalog components and inputs became generally available starting GitLab 17.0 (in GitLab.com and self-managed).

What about versioning components? Often a pipeline is coupled with the code, and we want a way to re-run a release pipeline from an older version of the code. Do we have options for version components similarly to how we do the application?

We have full support for version control – at any given time you can use any earlier version.

Can we have composite components that use multiple other components?

Absolutely! Here is an example of a deploy component that uses a validate component.

What are the options for testing components?

There are several methods of testing components. The first method is mentioned in the documentation: Including a component using $CI_COMMIT_SHA (instead of version), you can test your component for every single commit. Another strategy is to use child pipelines, which allows you to test a component with different inputs parameters. More details can be found in the GitLab forum.

Can the component reference URL use a branch name as the version, similar to how docs show a tag (e.g., $CI_SERVER_FQDN/my-org/security-components/secret-detection@master)?

Yes, you can use a branch name. The CI/CD Catalog documentation lists components versions.

How can you show the catalog in self-managed instances?

A self-managed catalog will be available, but will be empty without any published components. You can use this catalog internally in your organization and it is up for you and your teams to populate it with the appropriate components. Alternatively, you can mirror existing components projects from Gitlab.com to your self-managed instance.

Can we clone the public repo into a self-hosted instance?

A component is hosted in a GitLab project and like any other project it can be cloned locally. Follow these instructions on how to mirror a component from GitLab.com to self-managed instance.

How can you prevent name collisions with CI/CD component jobs?

Use inputs to specify dynamic job names, which will allow you to include the same component multiple times in the same pipeline.

Is it possible to inspect the source code of components in the catalog?

Yes, to view the source code, from the catalog open a component you would like to view. Then, click the component name – this will open the project where the component is hosted and you can find the component’s .yml file in the component's templates folder.

Can a component receive an array of data as input parameter?

A component can receive multiple data types such as string, boolean, number, and array.

Can the component reference more files alongside the .yml file?

No, it can’t. This capability is available in CI Steps (which is experimental).

Can we have anti-patterns for CI/CD components?

Please follow the best practice section in the documentation.

Is it possible to limit a group to only using components owned by the group (i.e., not allowing community components)?

Not yet, but this feature is on our roadmap.

Is the GitLab CI Steps feature related to this component in any way?

Yes, it is, we consider CI Steps as another type of component. More details can be found in the CI Steps documentation.

Is it possible to make private components for your organization only?

Yes, the component's visibility is based on the visibility level of your project and only members that have the privileges to see the project can view and search the component in the catalog.

What is the best approach if I need to fork a Gitlab.com component in terms of GitLab flow to manage the forked repo and propose changes when needed to the original repo?

You can manage your fork similarly to how you manage any Git repository – by making changes in your fork and then creating merge requests to propose changes back to the original repository.

Is there any difference in source code standardization between a verified creator and a non-verified creator in the catalog? Do verified creators have to follow a higher standard?

Currently, there is no process to verify and approve individual creators from our extended community. However. we do have a process for GitLab partners and GitLab-maintained components.

How would you recommend implementing tools like Fortify SCA into your CI/CD pipeline?

Two options would be possible: Either Fortify would need to create a shared component in the catalog that exposes the necessary elements for public consumption, or, if publicly-available APIs exist, the community can build an open-source component to be shared and used by others in the catalog.

What sort of patterns do you recommend for providing "outputs" from components that are consumed by other jobs/components in the including pipeline?

There is no ability to specify outputs for components, but this is on the roadmap with a new capability called CI Steps.

Is there any plan to label components?

Yes! in this GitLab epic, we have several issues to enhance searching and discoverability by content type, tags, and category.

Will existing CI/CD templates be migrated to components?

Yes, the GitLab templates are migrated and have a special badge in the CI/CD Catalog.

What's the recommended way to transition from our existing GitLab pipeline templates to GitLab catalog components?

This should be rather simple since components are very similar to templates. We would recommend start using inputs in your templates, and later on moving them to the appropriate folder structure.

For more detailed insights and best practices, visit the GitLab CI/CD Catalog documentation.