Reduce runner occupation by introducing workflow rules.
With gitlab CI it's easy to add workflow rules to only trigger pipelines for certain events. This way one can avoid to start pipelines for branches that are not ready to even start the pipeline etc. A simple workflow could be to run pipelines only when a merge request for a branch exists and when the merge does into the master (and releases). To do this the following lines have to be added to .gtilab-ci.yml
workflow:
rules:
- if: $CI_MERGE_REQUEST_ID # Execute jobs in merge request context
- if: $CI_COMMIT_BRANCH == 'master' # Execute jobs when a new commit is pushed to master branch
One could go even further and only trigger the pipelines when the merge request is not in WIP state.
workflow:
rules:
- if: '$CI_MERGE_REQUEST_ID && $CI_MERGE_REQUEST_TITLE !~ /^WIP/' # Execute jobs in merge request context and not in WIP status
- if: $CI_COMMIT_BRANCH == 'master' # Execute jobs when a new commit is pushed to master branch
The only downside here is that once the WIP is resolved then the pipelines are triggered on the next commit/push.
The CI can, btw, also be omitted manually by added -o ci.skip to the push command:
git push -o ci.skip origin branch_name
So the question is: Should we introduce this for the core modules.