Import/include common CI/CD content from one project into another's `.gitlab-ci.yml` (EE only?)
When companies have many projects, they often have standardized testing and deploying processes, which are often reflected in
.gitlab-ci.yml. We should make it easy to share these processes and DRY up CI/CD configuration by letting one project import/include from another project's repo; either its
.gitlab-ci.yml or another specified file. By allowing multiple imports, configuration could be componentized with a mix-and-max approach to constructing
Could be an EE feature, targeted at larger organizations.
include which contains a string or array of strings.
Use a fully-defined pipeline from another project:
Use template definitions:
include: same-group/template-repo/.gitlab-ci.yml test1: <<: *predefined_template
Mix-and-match template definitions:
include: - same-group/template-repo/.gitlab-ci-rspec.yml - same-group/template-repo/.gitlab-ci-rubocop.yml test1: <<: *rspec_template test2: <<: *rubocop_template
Include from arbitrary file, URL, or specific branch:
include: - group/project/directory/file.ext - user/project/directory/file.ext - https://server/url - group/project#branch
Using predefined templates seems like the recommended best practice, but the first way is a great way to get started, or use if a company has a rigid reusable process. It's comparable to including all of Twitter bootstrap vs including only the components you use.
Out of scope
Mix-and-match raw (direct import into job):
test1: include: same-group/template-repo/.gitlab-ci-rspec.yml test2: include: same-group/template-repo/.gitlab-ci-rubocop.yml
This last option might seem easier because you can ignore YAML templates, which are pretty awkward. But you quickly end up including the same file multiple times, buried deep in the config file, and that feels like an anti-pattern. Dropping this scope may also ensure that each included YAML file can be fully validated on its own.
- Requested here: https://forum.gitlab.com/t/ci-common-configuration/3862
- Older proposal: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/1258