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
p.s. Gitlab version used is 12.8.6