Assuming you want to have repeatable parts in your GitLab CI configuration, the YAML language itself has you covered. YAML’s anchors and extending allow you to reuse parts of your GitLab CI job configuration and extend on them.
To prevent GitLab CI from executing such shared blocks as jobs themselves, using hidden keys defined by using a dot (
.) in front of key names in YAML makes sure that GitLab recognizes those blocks as templates and doesn’t execute them.
The following example demonstrates how a job configuration is shared for 3 environments (
production) and how 3 dedicated CI jobs are created based on it using anchors, extending, and hidden keys.
Then, variables specific for each environment are defined in addition to that shared part.
image: node:12 stages: - install - build - deploy install: stage: install script: - npm ci artifacts: untracked: true expire_in: 1 hour .build: stage: build dependencies: - install script: - npm run build artifacts: untracked: true expire_in: 1 hour build-dev: <<: variables: REACT_APP_API_ENDPOINT: https://api-dev.example.com build-staging: <<: variables: REACT_APP_API_ENDPOINT: https://api-staging.example.com build-production: <<: variables: REACT_APP_API_ENDPOINT: https://api.example.com
&build is the YAML anchor,
.build is the hidden key, and
<<: *build is the YAML extend.
GitLab CI’s built-in extending
GitLab CI also offers an
extending configuration property that allows to reuse configuration sections as an alternative to the YAML-native anchors/extending.
.build: stage: build dependencies: - install script: - npm run build artifacts: untracked: true expire_in: 1 hour build-production: extending: .build variables: REACT_APP_API_ENDPOINT: https://api.example.com
While this seems a little more flexible/readable, it’s proprietary and harder to debug as YAML can simply be parsed or converted to e.g. resulting JSON using tooling outside of GitLab CI.