2

In order to stop the current default Gitlab behaviour of starting pipelines on branch creation I am trying to add a check in each job so that only merge requests trigger jobs when they have changes.

This is what I got so far:

  rules:
    - if: '[$CI_PIPELINE_SOURCE == "merge_request_event"] && [! git diff-index --quiet HEAD --]'

I am not quite familiar with bash which is surely the problem because I am currently encountering a 'yaml invalid' error :d

PS: Is there maybe a better way to do this instead of adding the check to each task?

ifrances
  • 21
  • 4

2 Answers2

0

i don't know if it can be useful, but Gitlab-ci provide the only job keyword that you can combine with changes and insert a path to files, in this way you can execute jobs only if there are changes on the code you are interested on.

Example

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  only:
    refs:
      - branches
    changes:
      - Dockerfile
      - docker/scripts/*
      - dockerfiles/**/*
      - more_scripts/*.{rb,py,sh}
      - "**/*.json"

DOC: https://docs.gitlab.com/ee/ci/yaml/#onlychanges--exceptchanges

Danilo Cacace
  • 482
  • 2
  • 8
  • Thank you for your reply. The problem I had with this approach is that "**/*" seems to be invalid, so I have to specify all extensions and that'd be delicate. I did have one draft with - "*.{severalTerminationsHere}" - "**/*.{severalTerminationsHere}" But if we forget some type or introduce a new one we'll have to modify this in all related jobs :S – ifrances Feb 10 '22 at 11:00
0

I am not quite familiar with bash which is surely the problem because I am currently encountering a 'yaml invalid' error :d

The issue seems to be with

[! git diff-index --quiet HEAD --]

You can not use bash syntax in Gitlab rules but to script section you can, as the name implies

In order to stop the current default Gitlab behaviour of starting pipelines on branch creation

If this is your goal I would recommend the following rules

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BEFORE_SHA == "0000000000000000000000000000000000000000"
      when: never
    - if: $CI_PIPELINE_SOURCE == "push"

Let's break down the aforementioned rules

The following rule will be true for merge requests

if: $CI_PIPELINE_SOURCE == "merge_request_event"

The predefined variable CI_COMMIT_BEFORE_SHA will be populated with this value 0000000000000000000000000000000000000000, when you create a new pipeline or a merge request

Therefore, the following rule will stop the execution of a new pipeline and of a merge request.

- if: $CI_COMMIT_BEFORE_SHA == "0000000000000000000000000000000000000000"
  when: never

BUT the merge requests are accepted from the previous rule, taking into account how gitlab evaluates them.

Quoting from https://docs.gitlab.com/ee/ci/jobs/job_control.html#specify-when-jobs-run-with-rules

Rules are evaluated in order until the first match. When a match is found, the job is either included or excluded from the pipeline

Finally, the following rule will be true for a new pushed commit

- if: $CI_PIPELINE_SOURCE == "push"

PS: Is there maybe a better way to do this instead of adding the check to each task?

The aforementioned rules dont have to be added for each job, but instead are configured once for each pipeline take a look https://docs.gitlab.com/ee/ci/yaml/workflow.html

Basicaly, add the workflow rules statement at the start of your gitlab.yml and you are good to go

Tolis Gerodimos
  • 3,782
  • 2
  • 7
  • 14
  • Thanks for the elaborated reply. I will try this and update – ifrances Feb 09 '22 at 14:15
  • Yeah it works like a marvel – ifrances Feb 10 '22 at 16:52
  • If it indeed works, please approve the answer and upvote. For future users to know that this fixed the problem. If you don't know how check this https://meta.stackexchange.com/questions/86978/how-do-i-accept-an-answer-on-stackoverflow – Tolis Gerodimos Feb 10 '22 at 17:02
  • I am reopening because when you do git push and then create an MR, the pipeline is not triggered – ifrances Feb 14 '22 at 18:12
  • @ifrances you are correct, the ordering of the rules i proposed was not correct. Updated answer and added more explanations. Please check again – Tolis Gerodimos Feb 14 '22 at 20:14