we are currently working on our CI/CD pipeline, in there we have some automation for testing and building a library, pushing a commit and tag to the repo with an automated account.
Is there a way that we can avoid pipeline triggers from this user?
The goal would be that no new pipeline would start, not even a skipped one, currently we added the push option ci.skip but that still creates a pipeline entry, which leads to the problem that our test coverage will not be shown on a merge request, because the last pipeline was just skipped…
Have you tried using workflow:rules as described here?
This controls if the whole pipeline is created or not. Maybe you can try adding a rule when not to trigger the pipeline - e.g (I didn’t test it personally!):
workflow:
rules:
- if: $GITLAB_USER_LOGIN == "automatedUser"
when: never
I guess this is because there is a new commit, which did not trigger any pipeline and the merge request tries to get the pipeline status of the latest commit?
Do you maybe know how to resolve this and use the latest run pipeline?
Yeeeahh… I know the problem. But I don’t know the solution Perhaps you can try enabling “Skipped pipelines”:
but this is just a wild guess. GitLab normally always tries to fetch the pipeline from latest commit on MR, and if it doesn’t find it, tends to hang, not allowing you to Merge if you have this “Pipelines must succeed” checked.
But I’m not sure if this will again influence your “coverage” (in a similar way as the skipped pipeline)
Otherwise, maybe you can rethink your workflow - is this additional commit you’re doing now and not needing to run pipeline for it - really what you need? Still sounds a bit odd to me that you need a commit which doesn’t run through the MR pipeline
Ok thanks for the recommendations, I will try them and update you on the outcome
I guess the commit is needed, because when the building is done a new library version tag should be pushed as well as an update bumpversion.cfg to represent the current version of the library.
Do you know an alternative how to do this?
I do it a bit differently actually. Mostly because our builds need to have version “baked in” to the build (executables/packages) itself, so I need to be able to provide version even before the build and pass to the build job as a variable or sth. So, my “version.txt” is already commited, then happens the build / test and everything else… git tagging of course at the end when creating release.
And why exactly do you need bumpversion.cfg - is it for some packaging purposes only? I have though similar situation with another file, when packing some .ipk packages and version has to be inside. But, I don’t commit this file. I just dynamically change the version inside (version is calculated also before the build), just during the pipeline for the packaging purposes, and don’t commit it - as it doesn’t really matter.
So maybe think if it really has to be commited or not? Maybe you can just change it temporarily on the fly and that’s it.
Just as an update the solution to enable skipped pipelines as success did not solve the problem, no the merge request can be closed but the coverage is not shown.
Yeah I thought about some automatic versioning where no manual interventions should be needed, therefore I use the bumpversion.cfg which is updated after every successful library build and pushed to the repo to keep it up to date.
Perhaps you can try enabling “Skipped pipelines”:
