Worflow rules for both MRs an conventional branches

Hello,

The project I work on has moved to Gitlab only a couple of weeks ago, and I could use some help with applying workflow rules in the pipeline definition.

With the change to Gitlab CI/CD, we have adopted the Gitflow workflow. (We might develop further in the future, but this we thought was a good starting point.) So there is a branch we call ‘dev’ where all development is done and there is a ‘master’ branch for the official releases of the project. Merge requests are created with respect to the ‘dev’ branch. When a release is approaching, we branch off from ‘dev’, finish the release and merge the branch both into ‘dev’ and into ‘master’. Hence, we need pipelines for both Merge Requests and for conventional branches.

Generally, pipelines shall trigger only when changes are pushed into the repository. Especially, MR creation and branch creation shall not trigger any pipelines in order to save build time. The reason for this is our presently limited capacity of the build resources.

In order to establish the desired behaviour, I have (naively) tried a workflow definition as follows:

workflow:
  rules:
    - if: $CI_MERGE_REQUEST_IID
      changes:
      - "**/*"
    - if: $CI_COMMIT_BRANCH 
      changes:
      - "**/*"

However, it doesn’t work as desired. When a Merge Requests without any changes is created, a pipeline gets triggered. When a conventional branch without any changes is created, a pipeline is triggered. I have tried many different twists and variations, but haven’t been able to find a definition satisfying the needs described above.

Even though I have studied the official documentation describing pipelines, workflows and rules carefully, reading it all over again and again, it seems that I am still missing something somewhere.

What would be the “right” way to setup workflow rules that work for both MRs and conventional branches?

Any help would be highly appreciated.

Thank you for your help
Marko

p.s. Gitlab version used is 12.8.6

Hello,
Any help would still be very appreciated.

Hi @ChildsEye! Welcome to our forum! I first want to apologize: you have been waiting since June 8 for a response from us. I must have missed this altogether - sorry about that!

Ok, I am going to take this straight to experts on setting up workflow rules. Can you link me to the docs you have already checked out so we don’t end up re-sending them over? Thanks! :blush:

Hello @Linds,
I am sorry for the delayed response, I was on an extended leave from my workplace until yesterday.

As for the workflow rules, I have studied official documentation quite intensively (also following all the links), this being the main source of wisdom.

Additionally I have also tried searching in this forum (this post looked promissing back then) as well as googling the internet, which would typically point to the same pages all over again.

Thank you for your effort in advance!

Best regards,
Marko

Hi @ChildsEye

in my repos, I also only want to trigger one pipeline for a feature branch, so I have something like this at the top of all my CI configs:

workflow:
    rules:
        - if: $CI_MERGE_REQUEST_ID
          when: never
        - if: $CI_COMMIT_TAG != null
          when: never
        - when: always

So, we don’t trigger a second pipeline for MRs and we don’t automatically trigger a pipeline when tags are pushed, but anything pushed to a feature branch (or merged into dev or master) gets a pipeline.

Personally, I would tend to stay away from changes, but when I build Dockerfiles I generally have something like this:

docker:
    stage: prepare
    ...
    rules:
        - if: '$CI_PIPELINE_SOURCE == "schedule"'
          when: never
        - changes:
              - .meta/Dockerfile
          when: always
        - when: never 

just because Docker builds are quite expensive in terms of CI time and I don’t want to wait around for them on every single push to a feature branch (but I do want to build the Dockerfile once at the start of every MR, at the very least).

The '$CI_PIPELINE_SOURCE == "schedule"' test means that scheduled pipelines run on the latest container that was built in the default branch.

Does that help?

Sarah

1 Like

Hello @snim2,

Thank you for the suggestion, I will try it out and report the results here.

Best regards,
Marko