I’m working on a CICD pipeline that has rules on when certain jobs execute. Some jobs should always execute, while others only execute when merged into main
, etc. It’s not behaving as I would expect and am interested if there is a way to report on past actions (merges, pushes, etc.) that shows why a pipeline/job did or didn’t execute.
I don’t think there’s anything quite like that. You can use the CI lint to validate your .gitlab-ci.yml
and simulate a pipeline on the default branch, but that doesn’t help with feature branches, etc.
Your best bet might be to either:
- turn on
CI_DEBUG_TRACE
for a while, - echo all the relevant variables to
STDOUT
, or - post a simplified version of your
.gitlab-ci.yml
file here.
Thank you for your response. Basically here’s the workflow I’m currently aiming for. Admittedly, this will evolve.
I have a main
branch that I create feature/bugfix branches from. These jobs should be triggered by creation or modification to files matching this rough regular expression. clusters/development/*/values.yaml
. I push feature/bugfix branch to Gitlab and create an MR. No deployment should take place. I create an MR, get it approved, and it merges into main
. Only then do I want the jobs to execute.
only:
changes:
- clusters/**
refs:
- main
Reading the troubleshooting page and it seems you and I have the same problem.
The
rules
oronly/except
keywords are what determine whether or not a job is added to a pipeline. If a pipeline runs, but a job is not added to the pipeline, it’s usually due torules
oronly/except
configuration issues.
So that “Changes” you have is always evaluating to true in this case. I have a similar pipeline that runs too often with:
rules:
if: '$CI_COMMIT_BRANCH == "master"'
changes:
- file1
- file2
when: always
Last time I inquired about a “only when certain files are changed on merge to the main branch” I was told “that is an interesting feature request”. Gitlab, afaik, has not moved quickly on this notion.
Thank you very much! It is useful.