CODEWITHSUNDEEP
continuous-integrationgitlab-cigitlab-ci-runner
Volker Stolz
Volker Stolz

Reputation: 7402

Running Gitlab-CI on project for two different Docker images

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: 1479

Answers (1)

Jakub Kania
Jakub Kania

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

Related Questions