Gerrit VCS trigger starting to many builds
"Hi Jetbrains
We're a team of devs. who use Gerrit and TeamCity in our daily work.
We're trying to set up a TeamCity configuration which, based on a "VCS Root" for Gerit and a "VCS Trigger", will start other builds using the REST API.
We're having issues understanding how the "VCS Trigger" option "Trigger a build on each check-in" works.
Steps to reproduce:
* Push a branch to Gerrit (git push origin HEAD:refs/for/master)
Expected behavior (with "Trigger a build on each check-in" checked):
* Each commit in the branch is queued once
Actual behavior (with "Trigger a build on each check-in" checked):
* The first commit in the branch gets queued once
* The second commit in the branch gets queued twice
* …
We're aware that Gerrit creates refs for each of the commits in our branch. But we don't believe that should cause the behavior we see.
Can you explain this behavior?"
Please sign in to leave a comment.
Hi,
Could you please share a screenshot of the VCS root (including branch specification) and trigger settings? Feel free to use our secure upload service for the upload, and share the upload ID here:
https://uploads.jetbrains.com/
Thanks
Hi
I have now provided 4 images on the Upload ID: 2026_04_07_YhqsRw1aoaJ1Up2iTuNdxH
Hi again
Do you have any updates on this matter, or is it equally as puzzling to you as it is to us?
Hi Again
We are still very much interested in hearing what could be the reason for the behavior we experience here.
Could you guys provide an update, is this something you are looking into?
Hi!
Sorry for the delay in getting back to you on this one. This is expected behavior given the
+:refs/changes/*in the branch specification together with the "Trigger a build on each check-in" option enabled on the VCS trigger. As the commits are chained, each change ref points to a commit whose history includes all the earlier commits in the stack. TeamCity treats every change ref as its own branch and calculates that branch's pending changes relative to master, so the first change in the stack has one new commit relative to master, the second change has two new commits, etc.Using “Trigger a build on each check-in”, TeamCity queues one build per individual commit it detects, as mentioned here . So a change branch that contains N new commits produces N builds, as confirmed by the screenshot of your build history ((change 57399/1 ran once, 57400/1 twice, etc.)
So if you want to get one build per change instead, turning off "Trigger a build on each check-in" on the trigger should do the trick.
Please let me know if this helps!