Skip to content

CI/CD components

DETAILS: Tier: Free, Premium, Ultimate Offering: SaaS, self-managed Status: Beta

A CI/CD component is a reusable single pipeline configuration unit. Use components to create a small part of a larger pipeline, or even to compose a complete pipeline configuration.

A component can be configured with input parameters for more dynamic behavior.

CI/CD components are similar to the other kinds of configuration added with the include keyword, but have several advantages:

  • Components can be listed in the CI/CD Catalog.
  • Components can be released and used with a specific version.
  • Multiple components can be defined in the same project and versioned together.

Instead of creating your own components, you can also search for published components that have the functionality you need in the CI/CD Catalog.

For an introduction and hands-on examples, see Efficient DevSecOps workflows with reusable CI/CD components.

Component project

A component project is a GitLab project with a repository that hosts one or more components. All components in the project are versioned together, with a maximum of 10 components per project.

If a component requires different versioning from other components, the component should be moved to a dedicated component project.

Create a component project

To create a component project, you must:

  1. Create a new project with a README.md file:

    • Ensure the description gives a clear introduction to the component.
    • Optional. After the project is created, you can add a project avatar.

    Components published to the CI/CD catalog use both the description and avatar when displaying the component project's summary.

  2. Add a YAML configuration file for each component, following the required directory structure. For example:

    spec:
  inputs:
    stage:
      default: test
---
component-job:
  script: echo job 1
  stage: $[[ inputs.stage ]]

You can use the component immediately, but you might want to consider publishing the component to the CI/CD catalog.

Directory structure

The repository must contain:

  • A README.md Markdown file documenting the details of all the components in the repository.
  • A top level templates/ directory that contains all the component configurations. You can define components in this directory:
    • In single files ending in .yml for each component, like templates/secret-detection.yml.
    • In sub-directories containing template.yml files as entry points, for components that bundle together multiple related files. For example, templates/secret-detection/template.yml.

NOTE: Optionally, each component can also have its own README.md file that provides more detailed information, and can be linked from the top-level README.md file. This helps to provide a better overview of your component project and how to use it.

You should also:

For example:

  • If the project contains a single component, the directory structure should be similar to:

    ├── templates/
│   └── my-component.yml
├── LICENSE.md
├── README.md
└── .gitlab-ci.yml

  • If the project contains multiple components, then the directory structure should be similar to:

    ├── templates/
│   ├── my-simple-component.yml
│   └── my-complex-component/
│       ├── template.yml
│       ├── Dockerfile
│       └── test.sh
├── LICENSE.md
├── README.md
└── .gitlab-ci.yml

    In this example:

    • The my-simple-component component's configuration is defined in a single file.
    • The my-complex-component component's configuration contains multiple files in a directory.

Use a component

To add a component to a project's CI/CD configuration, use the include: component keyword. The component reference is formatted as <fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version>, for example:

include:
  - component: gitlab.example.com/my-org/security-components/secret-detection@1.0
    inputs:
      stage: build

In this example:

  • gitlab.example.com is the Fully Qualified Domain Name (FQDN) matching the GitLab host. You can only reference components in the same GitLab instance as your project.
  • my-org/security-components is the full path of the project containing the component.
  • secret-detection is the component name that is defined as either a single file templates/secret-detection.yml or as a directory templates/secret-detection/ containing a template.yml.
  • 1.0 is the version of the component.

When GitLab creates a new pipeline, the component's configuration is fetched and added to the pipeline's configuration.

Component versions

In order of highest priority first, the component version can be:

  • A commit SHA, for example e3262fdd0914fa823210cdb79a8c421e2cef79d8.
  • A tag, for example: 1.0. If a tag and commit SHA exist with the same name, the commit SHA takes precedence over the tag.
  • A branch name, for example main. If a branch and tag exist with the same name, the tag takes precedence over the branch.
  • ~latest, which is a special version that always points to the most recent release published in the CI/CD Catalog.

NOTE: The ~latest version keyword always returns the most recent published release, not the release with the latest semantic version. For example, if you first release 2.0.0, and later release a patch fix like 1.5.1, then ~latest returns the 1.5.1 release. Issue #427286 proposes to change this behavior.

CI/CD Catalog

DETAILS: Tier: Free, Premium, Ultimate Offering: SaaS, self-managed Status: Beta

The CI/CD Catalog is a list of projects with published CI/CD components you can use to extend your CI/CD workflow.

Anyone can create a component project and add it to the CI/CD Catalog, or contribute to an existing project to improve the available components.

View the CI/CD Catalog

To access the CI/CD Catalog and view the published components that are available to you:

  1. On the left sidebar, select Search or go to.
  2. Select Explore.
  3. Select CI/CD Catalog.

Alternatively, if you are already in the pipeline editor in your project, you can select Browse CI/CD Catalog.

NOTE: Only public and internal projects are discoverable in the CI/CD Catalog.

Publish a component project

To publish a component project in the CI/CD catalog, you must:

  1. Set the project as a catalog resource.
  2. Publish a new release.

Set a component project as a catalog resource

To make published versions of a component project visible in the CI/CD catalog, you must set the project as a catalog resource.

Prerequisites:

  • You must have the Owner role in the project.

To set the project as a catalog resource:

  1. On the left sidebar, select Search or go to and find your project.
  2. Select Settings > General.
  3. Expand Visibility, project features, permissions.
  4. Turn on the CI/CD Catalog resource toggle.

The project only becomes findable in the catalog after you publish a new release.

Publish a new release

CI/CD components can be used without being listed in the CI/CD catalog. However, publishing a component's releases in the catalog makes it discoverable to other users.

Prerequisites:

To publish a new version of the component to the catalog:

  1. Add a job to the project's .gitlab-ci.yml file that uses the release keyword to create the new release. For example:

    create-release:
  stage: deploy
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  script: echo "Creating release $CI_COMMIT_TAG"
  rules:
    - if: $CI_COMMIT_TAG
  release:
    tag_name: $CI_COMMIT_TAG
    description: "Release $CI_COMMIT_TAG of components in $CI_PROJECT_PATH"

  2. Create a new tag for the release, which should trigger a tag pipeline that contains the job responsible for creating the release. You should configure the tag pipeline to test the components before running the release job.

After the release job completes successfully, the release is created and the new version is published to the CI/CD catalog.

Unpublish a component project

To remove a component project from the catalog, turn off the CI/CD Catalog resource toggle in the project settings.

WARNING: This action destroys the metadata about the component project and its versions published in the catalog. The project and its repository still exist, but are not visible in the catalog.

To publish the component project in the catalog again, you need to publish a new release.

Best practices

This section describes some best practices for creating high quality component projects.

Write a clear README.md

Each component project should have clear and comprehensive documentation. To write a good README.md file:

  • The documentation should start with a summary of the capabilities that the components in the project provide.
  • If the project contains multiple components, use a table of contents to help users quickly jump to a specific component's details.
  • Add a ## Components section with sub-sections like ### Component A for each component in the project.
  • In each component section:
    • Add a description of what the component does.
    • Add at least one YAML example showing how to use it.
    • If the component uses inputs, add a table showing all inputs with name, description, type, and default value.
    • If the component uses any variables or secrets, those should be documented too.
  • A ## Contribute section is recommended if contributions are welcome.

If a component needs more instructions, add additional documentation in a Markdown file in the component directory and link to it from the main README.md file. For example:

README.md    # with links to the specific docs.md
templates/
├── component-1/
│   ├── template.yml
│   └── docs.md
└── component-2/
    ├── template.yml
    └── docs.md

For an example of a component README.md, see the Deploy to AWS with GitLab CI/CD component's README.md.

Test the component

Testing CI/CD components as part of the development workflow is strongly recommended and helps ensure consistent behavior.

Test changes in a CI/CD pipeline (like any other project) by creating a .gitlab-ci.yml in the root directory. Make sure to test both the behavior and potential side-effects of the component. You can use the GitLab API if needed.

For example:

include:
  # include the component located in the current project from the current SHA
  - component: $CI_SERVER_HOST/$CI_PROJECT_PATH/my-component@$CI_COMMIT_SHA
    inputs:
      stage: build

stages: [build, test, release]

# Check if `component-job` is added.
# This example job could also test that the included component works as expected.
# You can inspect data generated by the component, use GitLab API endpoints, or third-party tools.
ensure-job-added:
  stage: test
  image: badouralix/curl-jq
  script:
    - |
      route="${CI_API_V4_URL}/projects/$CI_PROJECT_ID/pipelines/$CI_PIPELINE_ID/jobs"
      count=`curl --silent --header "PRIVATE-TOKEN: $API_TOKEN" $route | jq 'map(select(.name | contains("component-job"))) | length'`
      if [ "$count" != "1" ]; then
        exit 1
      fi

# If the pipeline is for a new tag with a semantic version, and all previous jobs succeed,
# create the release.
create-release:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG =~ /\d+/
  script: echo "Creating release $CI_COMMIT_TAG"
  release:
    tag_name: $CI_COMMIT_TAG
    description: "Release $CI_COMMIT_TAG of components repository $CI_PROJECT_PATH"

After committing and pushing changes, the pipeline tests the component, then creates a release if the earlier jobs pass.

Test a component against sample files

In some cases, components require source files to interact with. For example, a component that builds Go source code likely needs some samples of Go to test against. Alternatively, a component that builds Docker images likely needs some sample Dockerfiles to test against.

You can include sample files like these directly in the component project, to be used during component testing.

You can learn more in examples for testing a component.

Avoid using global keywords

Avoid using global keywords in a component. Using these keywords in a component affects all jobs in a pipeline, including jobs directly defined in the main .gitlab-ci.yml or in other included components.

As an alternative to global keywords:

  • Add the configuration directly to each job, even if it creates some duplication in the component configuration.
  • Use the extends keyword in the component, but use unique names that reduce the risk of naming conflicts when the component is merged into the configuration.

For example, avoid using the default global keyword:

# Not recommended
default:
  image: ruby:3.0

rspec-1:
  script: bundle exec rspec dir1/

rspec-2:
  script: bundle exec rspec dir2/

Instead, you can:

  • Add the configuration to each job explicitly:

    rspec-1:
  image: ruby:3.0
  script: bundle exec rspec dir1/

rspec-2:
  image: ruby:3.0
  script: bundle exec rspec dir2/

  • Use extends to reuse configuration:

    .rspec-image:
  image: ruby:3.0

rspec-1:
  extends:
    - .rspec-image
  script: bundle exec rspec dir1/

rspec-2:
  extends:
    - .rspec-image
  script: bundle exec rspec dir2/

Replace hardcoded values with inputs

Avoid using hardcoded values in CI/CD components. Hardcoded values might force component users to need to review the component's internal details and adapt their pipeline to work with the component.

A common keyword with problematic hard-coded values is stage. If a component job's stage is hardcoded, all pipelines using the component must either define the exact same stage, or override the configuration.

The preferred method is to use the input keyword for dynamic component configuration. The component user can specify the exact value they need.

For example, to create a component with stage configuration that can be defined by users:

  • In the component configuration:

    spec:
  inputs:
    stage:
      default: test
---
unit-test:
  stage: $[[ inputs.stage ]]
  script: echo unit tests

integration-test:
  stage: $[[ inputs.stage ]]
  script: echo integration tests

  • In a project using the component:

    stages: [verify, deploy]

include:
  - component: gitlab.com/gitlab-org/ruby-test@1.0
    inputs:
      stage: verify

Replace custom CI/CD variables with inputs

When using CI/CD variables in a component, evaluate if the inputs keyword should be used instead. Avoid asking users to define custom variables to configure components when inputs is a better solution.

Inputs are explicitly defined in the component's specs, and have better validation than variables. For example, if a required input is not passed to the component, GitLab returns a pipeline error. By contrast, if a variable is not defined, its value is empty, and there is no error.

For example, use inputs instead of variables to configure a scanner's output format:

  • In the component configuration:

    spec:
  inputs:
    scanner-output:
      default: json
---
my-scanner:
  script: my-scan --output $[[ inputs.scanner-output ]]

  • In the project using the component:

    include:
  - component: gitlab.example.com/my-scanner@1.0
    inputs:
      scanner-output: yaml

In other cases, CI/CD variables might still be preferred. For example:

Use semantic versioning

When tagging and releasing new versions of components, you should use semantic versioning. Semantic versioning is the standard for communicating that a change is a major, minor, patch, or other kind of change.

You should use at least the major.minor format, as this is widely understood. For example, 2.0 or 2.1.

Other examples of semantic versioning:

  • 1.0.0
  • 2.1.3
  • 1.0.0-alpha
  • 3.0.0-rc1

Convert a CI/CD template to a component

Any existing CI/CD template that you use in projects by using the include: syntax can be converted to a CI/CD component:

  1. Decide if you want the component to be grouped with other components as part of an existing component project, or create a new component project.
  2. Create a YAML file in the component project according to the directory structure.
  3. Copy the content of the original template YAML file into the new component YAML file.
  4. Refactor the new component's configuration to:
  5. Leverage the .gitlab-ci.yml in the components repository to test changes to the component.
  6. Tag and release the component.

You can learn more by following a practical example for migrating the Go CI/CD template to CI/CD component.

Troubleshooting

content not found message

You might receive an error message similar to the following when using the ~latest version qualifier to reference a component hosted by a catalog resource:

This GitLab CI configuration is invalid: component 'gitlab.com/my-namespace/my-project/my-component@~latest' - content not found`

The ~latest behavior was updated in GitLab 16.7. It now refers to the latest published version of the catalog resource. To resolve this issue, create a new release.