diff options
Diffstat (limited to 'doc/ci/components/index.md')
| -rw-r--r-- | doc/ci/components/index.md | 503 |
1 files changed, 284 insertions, 219 deletions
diff --git a/doc/ci/components/index.md b/doc/ci/components/index.md index 4a739bdfcf6..e73436522dc 100644 --- a/doc/ci/components/index.md +++ b/doc/ci/components/index.md @@ -2,29 +2,32 @@ stage: Verify group: Pipeline Authoring info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments -type: reference --- -# CI/CD Components (Experimental) +# CI/CD components **(FREE ALL EXPERIMENT)** > - Introduced as an [experimental feature](../../policy/experiment-beta-support.md) in GitLab 16.0, [with a flag](../../administration/feature_flags.md) named `ci_namespace_catalog_experimental`. Disabled by default. > - [Enabled on GitLab.com and self-managed](https://gitlab.com/groups/gitlab-org/-/epics/9897) in GitLab 16.2. -> - [Feature flag `ci_namespace_catalog_experimental` removed.](https://gitlab.com/gitlab-org/gitlab/-/issues/394772) in GitLab 16.3. +> - [Feature flag `ci_namespace_catalog_experimental` removed](https://gitlab.com/gitlab-org/gitlab/-/issues/394772) in GitLab 16.3. This feature is an experimental feature and [an epic exists](https://gitlab.com/groups/gitlab-org/-/epics/9897) to track future work. Tell us about your use case by leaving comments in the epic. -## Components Repository +## Components repository -A components repository is a GitLab project with a repository that hosts one or more pipeline components. A pipeline component is a reusable single pipeline configuration unit. You can use them to compose an entire pipeline configuration or a small part of a larger pipeline. It can optionally take [input parameters](../yaml/includes.md#define-input-parameters-with-specinputs). +A components repository is a GitLab project with a repository that hosts one or more pipeline components. +A pipeline component is a reusable single pipeline configuration unit. Use them to compose +an entire pipeline configuration or a small part of a larger pipeline. -### Create a components repository +A component can optionally take [input parameters](../yaml/inputs.md). + +## Create a components repository To create a components repository, you must: 1. [Create a new project](../../user/project/index.md#create-a-blank-project) with a `README.md` file. - -1. Create a `template.yml` file inside the project's root directory that contains the configuration you want to provide as a component. For example: +1. Create a `template.yml` file inside the project's root directory that contains the configuration you want to provide as a component. + For example: ```yaml spec: @@ -39,14 +42,71 @@ To create a components repository, you must: ### Directory structure -A components repository can host one or more components. +A components repository can host one or more components, and must follow a mandatory file structure. + +Component configurations can be saved through the following directory structure, containing: + +- A `templates` directory at the top level of your components repository. All component configuration files + should be saved under this directory. +- Files ending in `.yml` containing the component configurations, one file per component. +- A Markdown `README.md` file explaining the details of all the components in the repository. + +For example, if the project contains a single component and a pipeline to test the component, +the file structure should be similar to: + +```plaintext +├── templates/ +│ └── only_template.yml +├── README.md +└── .gitlab-ci.yml +``` + +This example component could be referenced with a path similar to `gitlab.com/my-username/my-component/only_template@<version>`, +if the project is: + +- On GitLab.com +- Named `my-component` +- In a personal namespace named `my-username` + +The templates directory and the suffix of the configuration file should be excluded from the referenced path. + +If the project contains multiple components, then the file structure should be similar to: + +```plaintext +├── README.md +├── .gitlab-ci.yml +└── templates/ + └── all-scans.yml + └── secret-detection.yml +``` + +These components would be referenced with these paths: -Components repositories must follow a mandatory file structure, containing: +- `gitlab.com/my-username/my-component/all-scans` +- `gitlab.com/my-username/my-component/secret-detection` + +You can omit the filename in the path if the configuration file is named `template.yml`. +For example, the following component could be referenced with `gitlab.com/my-username/my-component/dast`: + +```plaintext +├── README.md +├── .gitlab-ci.yml +├── templates/ +│ └── dast +│ └── template.yml +``` + +#### Component configurations saved in any directory (deprecated) + +NOTE: +Saving component configurations through this directory structure is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/415855). + +Components configurations can be saved through the following directory structure, containing: - `template.yml`: The component configuration, one file per component. If there is only one component, this file can be in the root of the project. If there are multiple components, each file must be in a separate subdirectory. -- `README.md`: A documentation file explaining the details of the all the components in the repository. +- `README.md`: A documentation file explaining the details of all the components in the repository. For example, if the project is on GitLab.com, named `my-component`, and in a personal namespace named `my-username`: @@ -60,6 +120,9 @@ namespace named `my-username`: └── .gitlab-ci.yml ``` + The `.gitlab-ci.yml` file is not required for a CI/CD component to work, but + [testing the component](#test-the-component) in a pipeline in the project is recommended. + This component is referenced with the path `gitlab.com/my-username/my-component@<version>`. - Containing one default component and multiple sub-components, then the file structure @@ -95,279 +158,281 @@ Nesting of components is not possible. For example: │ └── nested_template.yml ``` -### Test a component +## Release a component + +To create a release for a CI/CD component, use either: + +- The [`release`](../yaml/index.md#release) keyword in a CI/CD pipeline. Like in the + [component testing example](#test-the-component), you can set a component to automatically + be released after all tests pass in pipelines for new tags. +- The [UI for creating a release](../../user/project/releases/index.md#create-a-release). + +All released versions of the components are displayed in the CI/CD Catalog +page for the given resource, providing users with information about official releases. -Testing components as part of the development workflow to ensure that quality maintains high standards is strongly recommended. +Components [can be used](#use-a-component-in-a-cicd-configuration) without being released, +but only with a commit SHA or a branch name. To enable the use of tags or the `~latest` version keyword, +you must create a release. -Testing changes in a CI/CD pipeline can be done, like any other project, by creating a `.gitlab-ci.yml` in the root directory. +## Use a component in a CI/CD configuration +You can add a component to a CI/CD configuration with the `include: component` keyword. For example: ```yaml include: - # include the component located in the current project from the current SHA - - component: gitlab.com/$CI_PROJECT_PATH@$CI_COMMIT_SHA + - component: gitlab.example.com/my-namespace/my-component@1.0 inputs: stage: build - -stages: [build, test, release] - -# Expect `component-job` is added. -# This is an example of testing that the included component works as expected. -# You can leverage GitLab API endpoints or 3rd party tools to inspect data generated by the component. -ensure-job-added: - stage: test - image: badouralix/curl-jq - script: - - | - route="https://gitlab.com/api/v4/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 we are tagging a release with a specific convention ("v" + number) and all -# previous checks succeeded, we proceed with creating a release automatically. -create-release: - stage: release - image: registry.gitlab.com/gitlab-org/release-cli:latest - rules: - - if: $CI_COMMIT_TAG =~ /^v\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 releases it if the test passes. +The component is identified by a unique address in the form `<fully-qualified-domain-name>/<component-path>@<specific-version>`, +where: -### Release a component +- `<fully-qualified-domain-name>` matches the GitLab host. You can only reference components + in the same GitLab instance as your project. +- `<component-path>` is the component project's full path and directory where the + component YAML file is located. +- `<specific-version>` is the version of the component. In order of highest priority first, + the version can be: + - A branch name, for example `main`. + - A commit SHA, for example `e3262fdd0914fa823210cdb79a8c421e2cef79d8`. + - A tag, for example: `1.0`. If a tag and branch exist with the same name, the tag + takes precedence over the branch. If a tag and commit SHA exist with the same name, + the commit SHA takes precedence over the tag. + - `~latest`, which is a special version that always points to the most recent released tag. + Available only if the component has been [released](#release-a-component). -Component repositories are released using the [`release`](../yaml/index.md#release) keyword within a CI pipeline. +For example, for a component repository located at `gitlab-org/dast` on `gitlab.com`, +the path: -Like in the [example above](#test-a-component), after all tests pass in a pipeline running for a tag ref, we can release a new version of the components repository. +- `gitlab.com/gitlab-org/dast@main` targets the `template.yml` in the root directory + on the `main` branch. +- `gitlab.com/gitlab-org/dast@e3262fdd0914fa823210cdb79a8c421e2cef79d8` targets the same file + for the specified commit SHA. +- `gitlab.com/gitlab-org/dast@1.0` targets the same file for the `1.0` tag. +- `gitlab.com/gitlab-org/dast@~latest` targets the same file for the latest release. +- `gitlab.com/gitlab-org/dast/api-scan@main` targets a different file, the `template.yml` + in the `/api-scan` directory in the component repository, for the `main` branch. -All released versions of the components repository are displayed in the Components Catalog page for the given resource, providing users with information about official releases. +## Best practices -### Use a component in a CI/CD configuration +### Avoid using global keywords -A pipeline component is identified by a unique address in the form `<fully-qualified-doman-name>/<component-path>@<version>` -containing: +Avoid using [global keywords](../yaml/index.md#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. -- **A fully qualified domain name (FQDN)**: The FQDN must match the GitLab host. -- **A specific version**: The version of the component can be (in order of highest priority first): - - A commit SHA, for example `gitlab.com/gitlab-org/dast@e3262fdd0914fa823210cdb79a8c421e2cef79d8`. - - A tag. for example: `gitlab.com/gitlab-org/dast@1.0`. - - `~latest`, which is a special version that always points to the most recent released tag, - for example `gitlab.com/gitlab-org/dast@~latest`. - - A branch name, for example `gitlab.com/gitlab-org/dast@main`. -- **A component path**: Contains the project's full path and the directory where the component YAML file `template.yml` is located. +As an alternative to global keywords, instead: -For example, for a component repository located at `gitlab-org/dast` on `gitlab.com`: +- Add the configuration directly to each job, even if it creates some duplication + in the component configuration. +- Use the [`extends`](../yaml/index.md#extends) keyword in the component. -- The path `gitlab.com/gitlab-org/dast` tries to load the `template.yml` from the root directory. -- The path `gitlab.com/gitlab-org/dast/api-scan` tries to load the `template.yml` from the `/api-scan` directory. +For example, using the `default` keyword is not recommended: -**Additional notes:** +```yaml +# Not recommended +default: + image: ruby:3.0 -- You can only reference components in the same GitLab instance as your project. -- If a tag and branch exist with the same name, the tag takes precedence over the branch. -- If a tag is named the same as a commit SHA that exists, like `e3262fdd0914fa823210cdb79a8c421e2cef79d8`, - the commit SHA takes precedence over the tag. +rspec-1: + script: bundle exec rspec dir1/ -### Best practices +rspec-2: + script: bundle exec rspec dir2/ +``` -#### Avoid using global keywords +Instead, you can: -When using [global keywords](../yaml/index.md#global-keywords) all jobs in the -pipeline are affected. Using these keywords in a component affects all jobs in a -pipeline, whether they are directly defined in the main `.gitlab-ci.yml` or -in any included components. +- Add the configuration to each job: -To make the composition of pipelines more deterministic, either: + ```yaml + rspec-1: + image: ruby:3.0 + script: bundle exec rspec dir1/ -- Duplicate the default configuration for each job. -- Use [`extends`](../yaml/index.md#extends) feature within the component. + rspec-2: + image: ruby:3.0 + script: bundle exec rspec dir2/ + ``` -```yaml -## -# BAD -default: - image: ruby:3.0 +- Use `extends` to reuse configuration: -rspec: - script: bundle exec rspec -``` + ```yaml + .rspec-image: + image: ruby:3.0 -```yaml -## -# GOOD -rspec: - image: ruby:3.0 - script: bundle exec rspec -``` + rspec-1: + extends: + - .rspec-image + script: bundle exec rspec dir1/ -#### Replace hard-coded values with inputs + rspec-2: + extends: + - .rspec-image + script: bundle exec rspec dir2/ + ``` -A typical hard-coded value found in CI templates is `stage:` value. Such hard coded values may force the user -of the component to know and adapt the pipeline to such implementation details. +### Replace hard-coded values with inputs -For example, if `stage: test` is hard-coded for a job in a component, the pipeline using the component must -define the `test` stage. Additionally, if the user of the component want to customize the stage value it has -to override the configuration: +Avoid hard-coding values in CI/CD components. Hard-coded values might force +component users to need to review the component's internal details and adapt their pipeline +to work with the component. -```yaml -## -# BAD: In order to use different stage name you need to override all the jobs -# included by the component. -include: - - component: gitlab.com/gitlab-org/ruby-test@1.0 +A common keyword with problematic hard-coded values is `stage`. If a component job's +stage is set to a specific value, the pipeline using the component **must** define +the exact same stage. Additionally, if the component user wants to use a different stage, +they must [override](../yaml/includes.md#override-included-configuration-values) the configuration. -stages: [verify, deploy] +The preferred method is to use the [`input` keyword](../yaml/inputs.md). +The component user can specify the exact value they need. -unit-test: - stage: verify +For example: -integration-test: - stage: verify -``` +- In the component configuration: -```yaml -## -# BAD: In order to use the component correctly you need to define the stage -# that is hard-coded in it. -include: - - component: gitlab.com/gitlab-org/ruby-test@1.0 + ```yaml + spec: + inputs: + stage: + default: test + --- + unit-test: + stage: $[[ inputs.stage ]] + script: echo unit tests + + integration-test: + stage: $[[ inputs.stage ]] + script: echo integration tests + ``` -stages: [test, deploy] -``` +- In the project using the component: -To improve this we can use [input parameters](../yaml/includes.md#define-input-parameters-with-specinputs) -allowing the user of a component to inject values that can be customized: + ```yaml + include: + - component: gitlab.com/gitlab-org/ruby-test@1.0 + inputs: + stage: verify -```yaml -## -# GOOD: We don't need to know the implementation details of a component and instead we can -# rely on the inputs. -include: - - component: gitlab.com/gitlab-org/ruby-test@1.0 - inputs: - stage: verify + stages: [verify, deploy] + ``` -stages: [verify, deploy] +### Replace custom CI/CD variables with inputs -## -# inside the component YAML: -spec: - inputs: - stage: - default: test ---- -unit-test: - stage: $[[ inputs.stage ]] - script: echo unit tests +When using CI/CD variables in a component, evaluate if the `inputs` keyword +should be used instead. Avoid requiring a user to define custom variables to change a component's +behavior. You should try to use `inputs` for any component customization. -integration-test: - stage: $[[ inputs.stage ]] - script: echo integration tests -``` +Inputs are explicitly defined in the component's specs, and are better validated 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. -#### Prefer inputs over variables +For example, use `inputs` instead of variables to let users change a scanner's output format: -If variables are only used for YAML evaluation (for example `rules`) and not by the Runner -execution, it's advised to use inputs instead. -Inputs are explicitly defined in the component's contract and they are better validated -than variables. +- In the component configuration: -For example, if a required input is not passed an error is returned as soon as the component -is being used. By contrast, if a variable is not defined, it's value is empty. + ```yaml + spec: + inputs: + scanner-output: + default: json + --- + my-scanner: + script: my-scan --output $[[ inputs.scanner-output ]] + ``` -```yaml -## -# BAD: you need to configure an environment variable for a custom value that doesn't need -# to be used on the Runner -unit-test: - image: $MY_COMPONENT_X_IMAGE - script: echo unit tests - -integration-test: - image: $MY_COMPONENT_X_IMAGE - script: echo integration tests - -## -# Usage: -include: - - component: gitlab.com/gitlab-org/ruby-test@1.0 +- In the project using the component: -variables: - MY_COMPONENT_X_IMAGE: ruby:3.2 -``` + ```yaml + include: + - component: gitlab.example.com/my-scanner@1.0 + inputs: + scanner-output: yaml + ``` -```yaml -## -# GOOD: we define a customizable value and accept it as input -spec: - inputs: - image: - default: ruby:3.0 ---- -unit-test: - image: $[[ inputs.image ]] - script: echo unit tests +In other cases, CI/CD variables are still preferred, including: -integration-test: - image: $[[ inputs.image ]] - script: echo integration tests +- Using [predefined variables](../variables/predefined_variables.md) to automatically configure + a component to match a user's project. +- Requiring tokens or other sensitive values to be stored as [masked or protected variables in project settings](../variables/index.md#define-a-cicd-variable-in-the-ui). -## -# Usage: -include: - - component: gitlab.com/gitlab-org/ruby-test@1.0 - inputs: - image: ruby:3.2 -``` +### Use semantic versioning -#### Use semantic versioning +When tagging and releasing new versions of components, you should use [semantic versioning](https://semver.org). +Semantic versioning is the standard for communicating that a change is a major, minor, patch, +or other kind of change. -When tagging and releasing new versions of components we recommend using [semantic versioning](https://semver.org) -which is the standard for communicating bugfixes, minor and major or breaking changes. +You should use at least the `major.minor` format, as this is widely understood. For example, +`2.0` or `2.1`. -We recommend adopting at least the `MAJOR.MINOR` format. +Other examples of semantic versioning: -For example: `2.1`, `1.0.0`, `1.0.0-alpha`, `2.1.3`, `3.0.0-rc.1`. +- `1.0.0` +- `2.1.3` +- `1.0.0-alpha` +- `3.0.0-rc1` -## CI/CD Catalog **(PREMIUM ALL)** +### Test the component -The CI/CD Catalog is a list of [components repositories](#components-repository), -each containing resources that you can add to your CI/CD pipelines. +Testing CI/CD components as part of the development workflow is strongly recommended +and helps ensure consistent behavior. -### Mark the project as a catalog resource +Test changes in a CI/CD pipeline (like any other project) by creating a `.gitlab-ci.yml` +in the root directory. -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/407249) in GitLab 16.1. +For example: -After components are added to a components repository, they can immediately be [used](#use-a-component-in-a-cicd-configuration) to build pipelines in other projects. +```yaml +include: + # include the component located in the current project from the current SHA + - component: gitlab.com/$CI_PROJECT_PATH@$CI_COMMIT_SHA + inputs: + stage: build -However, this repository is not discoverable. You must mark this project as a catalog resource to allow it to be visible in the CI Catalog -so other users can discover it. +stages: [build, test, release] -To mark a project as a catalog resource: +# Expect `component-job` is added. +# This example tests 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="https://gitlab.com/api/v4/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 -1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project. -1. On the left sidebar, select **Settings > General**. -1. Expand **Visibility, project features, permissions**. -1. Scroll down to **CI/CD Catalog resource** and select the toggle to mark the project as a catalog resource. +# If we are tagging a release with a specific convention ("v" + number) and all +# previous checks succeeded, we proceed with creating a release automatically. +create-release: + stage: release + image: registry.gitlab.com/gitlab-org/release-cli:latest + rules: + - if: $CI_COMMIT_TAG =~ /^v\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" +``` -NOTE: -This action is not reversible. +After committing and pushing changes, the pipeline tests the component, then releases it if the test passes. -## Convert a CI template to component +## Convert a CI/CD template to a component -Any existing CI template, that you share with other projects via `include:` syntax, can be converted to a CI 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 whether you want the component to be part of an existing [components repository](#components-repository), - if you want to logically group components together. Create and setup a [components repository](#components-repository) otherwise. -1. Create a YAML file in the components repository according to the expected [directory structure](#directory-structure). -1. Copy the content of the template YAML file into the new component YAML file. -1. Refactor the component YAML to follow the [best practices](#best-practices) for components. -1. Leverage the `.gitlab-ci.yml` in the components repository to [test changes to the component](#test-a-component). -1. Tag and [release the component](#release-a-component). +1. Decide if you want the component to be part of an existing [components repository](index.md#components-repository) + to be grouped with other components, or create and set up a new components repository. +1. Create a YAML file in the components repository according to the expected [directory structure](index.md#directory-structure). +1. Copy the content of the original template YAML file into the new component YAML file. +1. Refactor the new component's configuration to: + - Follow the [best practices](index.md#best-practices) for components. + - Improve the configuration, for example by enabling [merge request pipelines](../pipelines/merge_request_pipelines.md) + or making it [more efficient](../pipelines/pipeline_efficiency.md). +1. Leverage the `.gitlab-ci.yml` in the components repository to [test changes to the component](index.md#test-the-component). +1. Tag and [release the component](index.md#release-a-component). |