Gitlab pipelines only/except for WIP merge requests

At ioxp we automate our continuous integration using the awesome Gitlab project. However, their model of when testing jobs run on commits induced quite a heavy load on our testing servers. So we were very delighted when pipelines for merge requests were introduced in Gitlab 11.6.

We then configured our testing to run with

only:merge_requests

However, our development process (more on that in a later post) recommends:

If a developer starts working on an issue, they have to

1. (if not already done) assign them
2. Create a branch starting with their two-letter initials, like ph/purposeOfTheBranch,
3. Open a new WIP merge request mentioning the issue to mark that it is currently being worked on,
4. Assign themselves to the merge request because they are currently responsible for it

We do this to have a nice overview about what is currently going on and to discuss about unfinished work. However, our only:merge_requests became useless now – as every implementation starts with a merge request, the pipelines are immediately started wasting CI time.

Luckily, variables expressions came to our rescue:

integrationtest:
  stage: integrationtest
  tags:
    - withBackend
  only:
    - merge_requests
  except:
    variables:
      - $CI_MERGE_REQUEST_TITLE =~ /^WIP:.*/

It is as easy as that.

2 thoughts on “Gitlab pipelines only/except for WIP merge requests

  1. How is your process when the WIP is finally removed?
    How do you make sure your complete tests are run before someone can click the merge button?
    Do you trigger the pipeline manually?

    1. Unfortunately, Gitlab currently has no trigger when the WIP status changes: https://gitlab.com/gitlab-org/gitlab/-/issues/25426

      So what we did here was to add an additional job to the pipeline, running only for WIP and in the last stage which just fails with the message “this pipeline ran on a WIP merge request”.

      However, since Gitlab back then did not not allow to trigger an MR pipeline manually (without any code changes), we always had to make sure that we 1) first removed the WIP and 2) then pushed the new changes which resolved the WIP-ness.

      In the end, this was shown to be a cumbersome process due to the two missing Gitlab features missing and nowadays we have stopped using different pipelines for WIP and non-WIP merge requests.
      The second feature (Manually triggering a MR pipeline) was added in Gitlab 12.3 (https://about.gitlab.com/releases/2019/09/22/gitlab-12-3-released/#run-pipeline-button-for-merge-request-pipelines) but at the time we upgraded to it, we already had changed our pipeline.

Leave a Reply

Your comment will be moderated.

This site uses Akismet to reduce spam. Learn how your comment data is processed.