Question

我们有一个小型C ++项目，它集成在本地Gitlab安装中。 QA（通过具有预期输出的shell脚本进行本地单元测试）通过.gitlab-ci.yml使用特定的Docker镜像（image: ubuntu:artful）完成。由于存在细微差别，我们希望在image: debian:stretch上运行相同的测试，这当然需要CI-config中的小差异。

我目前正在做的是维护一个单独的分支，它有自己的.gitlab-ci.yml，它在image - 部分不同，而且不同阶段的主体差异很小（不同的包到{{ 1}}等。这意味着我需要经常将apt-get重新绑定到该分支，并确保手动将更改合并到ci-config。

这不太好：在我以前的生活中，我使用了Jenkins，在那里我可以轻松地在实际仓库之外维护不同的CI设置（我完全得到GitLab解决了在版本控制下使CI-config本身的问题）。

我想我可以解决两个分支之间gitlab-config的所有细微差别，这些变量取决于我所在的分支，除了docker镜像。

我看到两种不同的解决方案，以避免仅为CI目的维护这两个分支：1）让Gitlab维护者安装一个带有所需图像的VM，并注册一个特定的额外运行器，或2）使用预定的管道在master - 分支上，我可以将图像名称作为参数传递。

解决方案1）对我来说似乎是最干净的，但是不在我的手中（并且仍然需要对gitlab-ci配置中的变量进行特殊的套管/泛化）。是否有另一种方法可以在单个项目中运行多个 gitlab-ci配置而不会有太多麻烦？

Answer 1

嗯，还有第三种选择，但根据你所拥有的测试次数，它可能不是更清洁。 Yaml支持anchors，因此您可以为每个测试定义一个模板，然后执行它的两个实例。专业人员包括两组测试在同一个管道中并行运行，因为它可能会变得混乱，如果其中一个管道出现故障，管道就会停止。

.job_template: &job_definition
  stage: test  
  services:
    - postgres
    - redis
  script:
    - run tests

test_a:
  <<: *job_definition
  image: ubuntu:artful
  variables:
     SOME_VAR: "override variable"

test_s:
  <<: *job_definition 
  image: debian:stretch
  before_script:
    - do some special preparations

在项目上运行Gitlab-CI以获取两个不同的Docker镜像

1 个答案: