When I do multiple commits on my local repo, and then push, only the latest commit triggers the CI pipeline. Is it possible to trigger the pipeline for the intermediate commits as well?
1 Like
What do you mean?
Your commit stacks each other when you’re on the same branch?
Yes, I am only on the master branch. Then, on my local repo, I do a series of commits (all to master). When I am done, I push to gitlab.com. All the local commits do not trigger the pipeline. Only the last one triggers the pipeline.
I don’t understand the problem, if you commit on the same branch, each commit is contained in the last commit ?
No, the commits are listed separately on Gitlab after I push. But the CI pipeline is triggered only on the last one.
Here is an example of the issue. This is a section of the list of my commits as it looks on Gitlab.com for a project of mine.
I did these three commits locally in my PC, and then pushed to Gitlab.com. As you can see the pipeline executed only for the last commit (e029ad28), as indicated by the green checkmark.
I want the pipeline to run for ALL the commits, even if I push a bunch of commits together.
Yes, this is the case for everyone.
What’s the point on running the tests for each commit if they’re contained in the last one …
Running the tests for the last commit is enough to test your whole application, don’t try to change this behaviour, you will loose time for nothing
Okay. I would at least like to have the option of running the tests on the other commits. If the test on the last commit fails, I can run the tests on the previous commits as well to help me pinpoint exactly what change caused the tests to fail. It is easier to diff two consecutive commits than diffing commits that are far apart.
I want to point out a valid usecase for this feature. If you project is configured for ffwd only merge, it is very helpful to have the pipeline test each commit from an MR for the sake of making bisect work well on master. If each commit has had pipeline coverage, you don’t need to root out stray intermediate commits where things may be broken for some other reason than what you are currently debugging.
Only way I can think to get coverage on each commit today is to limit an MR to only a single commit. This is not ideal since then one of two things end up happening: either your commits become large, which makes reviews and debug through bisection more difficult OR they stay small but you have many many small MRs which is not a very efficient process.
2 Likes
Did you find a solution ?
Stumbled also on the same issue:-(
I consider having a per-commit CI as a fundamental aspect for enabling healthy collaboration of developers, as well as the debug considerations as are already laid out above. Of course there should be additional schemes that execute on a wider granularity, as the per-commit CI should be quick, still I consider it mandatory.
Are there any plans to resolve this?
2 Likes