GitLab 11.7 推出了新的 include 方法，例如 include:file：
https://docs.gitlab.com/ee/ci/yaml/#includefile
include:
- project: 'my-group/my-project'
ref: master
file: '/templates/.gitlab-ci-template.yml'
这将允许您在同一GitLab实例上创建一个新项目，其中包含一个共享的.gitlab-ci.yml文件。
首先，让我说一声：谢谢您提出这个问题！这激励我再次寻找解决方案，因为我经常在想这是否可能。我们还有20-30个项目非常相似，并且每个项目都有大约400-500行代码的.gitlab-ci.yml文件，如果有变更，则必须更改这些文件。
因此，我找到了一个可行的解决方案：
受Gitlab本身创建的自动 DevOps .gitlab-ci.yml 模板的启发，他们使用一个模板作业定义所有使用的函数并调用每个before_script来加载它们，我想出了以下设置。
文件
因此，使用共享的CI作业脚本：
#!/bin/bash
function list_files {
ls -lah
}
function current_job_info {
echo "Running job $CI_JOB_ID on runner $CI_RUNNER_ID ($CI_RUNNER_DESCRIPTION) for pipeline $CI_PIPELINE_ID"
}
一个常见且通用的.gitlab-ci.yml文件：
image: ubuntu:latest
before_script:
# Install curl
- apt-get update -qqq && apt-get install -qqqy curl
# Get shared functions script
- curl -s -o functions.sh https://gitlab.com/giix/demo-shared-ci-functions/raw/master/functions.sh
# Set permissions
- chmod +x functions.sh
# Run script and load functions
- . ./functions.sh
job1:
script:
- current_job_info
- list_files
sh）.gitlab-ci.yml 文件。
自定义该文件路径：
- 进入项目设置 > CI/CD。
- 展开“通用流水线”部分。
- 在“自定义 CI 配置路径”字段中提供值。
- 单击“保存更改”。 ...
如果 CI 配置将托管在外部站点上，则 URL 必须以 .yml 结尾：
http://example.com/generate/ci/config.yml
如果 CI 配置将托管在 GitLab 的其他项目中，则该路径必须相对于其他项目中的根目录，并在末尾添加组和项目名称：
.gitlab-ci.yml@mygroup/another-project
my/path/.my-custom-file.yml@mygroup/another-project
所以，我想现在分享一下我的想法：
目前我们采用了@stefan-van-gastel的共享ci库和gitlab 11.7相对较新的include功能的混合方法。我们非常满意这种方法，因为现在我们可以在单个存储库中管理40多个存储库的构建流水线。
我创建了一个名为ci_shared_library的存储库，其中包含：
pipeline.yml文件包含整个流水线配置，在脚本之前我们将ci_shared_library加载到/tmp/shared中以便执行脚本。stages:
- test
- build
- deploy
- validate
services:
- docker:dind
before_script:
# Clear existing shared library
- rm -rf /tmp/shared
# Get shared library
- git clone https://oauth2:${GITLAB_TOKEN}@${SHARED_LIBRARY} /tmp/shared
- cd /tmp/shared && git checkout master && cd $CI_PROJECT_DIR
# Set permissions
- chmod -R +x /tmp/shared
# open access to registry
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
test:
stage: test
script:
- /tmp/shared/test.sh
build:
stage: build
script:
- /tmp/shared/build.sh
artifacts:
paths:
- $CI_PROJECT_DIR/target/RPMS/x86_64/*.rpm
expire_in: 3h
only:
- develop
- /release/.*/
deploy:
stage: deploy
script:
- /tmp/shared/deploy.sh
artifacts:
paths:
- $CI_PROJECT_DIR/tmp/*
expire_in: 12h
only:
- develop
- /release/.*/
validate:
stage: validate
script:
- /tmp/shared/validate.sh
only:
- develop
- /release\/.*/
每个想要使用此管道配置的项目都必须有一个.gitlab-ci.yml文件。在这个文件中，唯一需要做的是从ci_shared_library仓库导入共享的pipeline.yml文件。
# .gitlab-ci.yml
include:
- project: 'ci_shared_library'
ref: master
file: 'pipeline.yml'
通过这种方法，与管道相关的所有内容都放在一个单一的存储库中，并且可以重复使用。我们把整个管道模板都放在一个文件中，但我认为甚至可以将其拆分成每个作业都有一个yml文件。这样，它将更加灵活，人们可以创建默认作业，以不同方式合并具有相似作业但并非每个项目都需要所有作业的项目...
pipeline.yml中获取整个流水线。如果该文件告诉它拉取ci_shared_library存储库的develop分支，那就完全没问题。但可能有点令人困惑 ;) - pyriand3rinclude 功能更加实用：
使用API验证扩展的GitLab CI/CD配置
编写和调试复杂的流水线并非易事。您可以使用
include关键字来帮助减少流水线配置文件的长度。但是，如果您以前想要通过API验证整个流水线，则必须单独验证每个包含的配置文件，这很复杂且耗时。
现在您有能力通过API验证完全展开的流水线配置，包括所有
include配置。
调试大型配置现在更加容易和高效。
以及：
查看 GitLab 13.6 (2020年11月)：
将多个CI/CD配置文件作为列表包含
以前，当使用
include:file语法向您的CI/CD配置添加多个文件时，您必须为每个文件指定项目和ref。在此版本中，您现在可以一次性指定项目、ref，并提供文件列表。这样可以避免重复操作，使流水线配置更简洁。
使用Jsonnet动态生成子管道配置
现在，我们通过包含一个项目模板来演示如何使用Jsonnet生成YAML，使得在运行时创建CI/CD YAML变得更加容易。我们在GitLab 12.9中发布了 Dynamic Child Pipelines，这使您能够在运行时生成整个
.gitlab-ci.yml文件。
例如，对于单体库（monorepos），当您希望运行时行为更加动态时，这是一个很好的解决方案。
publish-java: {script: 'ci/publish-java.sh'}，例如。而且我没有 'before_script'，而是在顶部定义了variables: { GIT_SUBMODULE_STRATEGY: 'recursive' }。https://gist.github.com/lordvlad/1ad18dc44479f2b90735bdb96b1d5338 - lordvlad