Reputation: 7402
We have a small C++ project that is integrated on a local Gitlab installation. QA (a home-grown unit test via a shell-script with expected output) is done through .gitlab-ci.yml
with a specific Docker image (image: ubuntu:artful
). Due to subtle differences, we want to run the same tests also on image: debian:stretch
, which requires of course small differences in the CI-config.
What I am currently doing is maintaining a separate branch with it's own .gitlab-ci.yml
, which differs in the image
-section, and small differences in the bodies of the different stages (different packages to apt-get
etc.). That means I need to rebase master
frequently into that branch, and make sure to manually merge changes to the ci-config.
This is not nice: in my previous life I used Jenkins, where I could easily maintain different CI-setups outside of the actual repo (I totally do get that GitLab solves the problem of having the CI-config itself under version control).
I think I could work around all the small differences in the gitlab-config between both branches with variables depending on the branch that I'm in, except for the docker image.
I see two different solutions to avoid maintaining those two branches just for CI purposes: 1) get the Gitlab-maintainers do install a VM with the required image instead, and register a specific additional runner, or 2) use a scheduled pipeline on the master
-branch where I could pass in the image-name as a parameter.
Solution 1) seems the cleanest for me, but is out of my hands (and still requires special-casing/generalisation to variables inside the gitlab-ci config). Is there another way to run multiple gitlab-ci configurations in a single project without too much hassle?
Upvotes: 0
Views: 1476
Reputation: 16487
Well, there's a third option but depending on the number of tests you have it may not be cleaner. Yaml supports anchors so you can define a template for each test and then do two instances of it. The pros include that both sets of test run in parallel in the same pipeline, the con is that it may get messy and pipeline will stop if one of them fails.
.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
Upvotes: 2