Unexpected \ Undesired VCS Trigger behavior
I am not getting the behavior I except or desire for a VCS Trigger with the following features:
- Trigger a build on each check-in
- Include several check-ins in a build if they are from the same committer.
- A long quiet period (1 Day)
If there is a chain of commits from one user there is of course no-builds triggered. I would expect / desire as soon as a change from another committer happens then the chain of commits from the first committer should have a build queued. But no builds are scheduled until the quite period has elapsed and then multiple build are scheduled.
Is this the expected behavior? It there a justification beyond it was the easy to implement and test?
What I want is to trigger the smallest set of regression test builds where each committer's changes is run in a separate build and have descent response time for the regression failures. A schedule trigger will do all the currently pending commits, and the VCS trigger with a long quite period can take too long a time before scheduling any work.
A schedule trigger that triggers work like the VCS trigger with grouping commits would also work for me.
Does anyone have solution to my problem other than an integration or custom trigger?
thank you.
Please sign in to leave a comment.
Hi Chris,
There are two different "wait" periods to configure on VCS Roots and triggers. One is the "Changes checking interval", which means how often TeamCity will ping the server to know whether there are changes or not. The other one, is the quiet period. This means that, once a build is triggered, it will wait at least the quiet period before a new build is triggered with that same trigger. This is to prevent situations where several commits are sent right after each other and that triggers several builds, which could lead to problems.
If your objective is to have the builds trigger as soon as they are committed, then the quiet period should be substantially reduced.
If you want to have builds trigger instantly as commits are added you can, additionally to changing the quiet period:
-Reduce the checking for changes interval
-Add a commit hook to the repository: https://confluence.jetbrains.com/display/TCD10/Configuring+VCS+Post-Commit+Hooks+for+TeamCity
Hello Denis
Thanks for your reply. I don't want _all_ the pending commits started just some in some cases. For instances suppose we have two committer who make the following changes in with the time less than quite period between them.
then after the quite period with out commits the VCS trigger I describe will trigger 3 builds:
What I would like to happen is to have the builds with the previous committer started when committer changes so, shortly after commit 3 happens the build with 1 and 2 would be started. Then after commit 4 happens the build with 1,2 and 3 would be started. The build with all the changes would not be started until the quite period has elapsed without commits. What I want is for the trigger to be more eager to start work that it knows by it rules is to be done. This is I suspect a bit more code that the current TC VCS trigger and only happens in with one of the configurations.
Alternatively a Scheduled trigger with similar behavior of starting multiple builds at once would be OK.
I suspect that I need to write an RESTful integration or custom build trigger for this solution, however, I did not find the custom build trigger guide heartening. Could JetBrains post / open source the code for some of their triggers? the examples provide don't show the proper way to interact with a TC VCS root object.
Thank you.
Hi Chris,
I see what you are trying to accomplish, and definitely it's not doable with our current implementations.
Regarding our triggers, we do have one sample open sourced: https://confluence.jetbrains.com/display/TW/Url+Build+Trigger
An option using the REST API would be to remove the quiet period altogether, and move the trigger to a separate configuration, which upon start will manually run the checks you want, then trigger a build using the REST API: https://confluence.jetbrains.com/display/TCD10/REST+API#RESTAPI-TriggeringaBuild
Hi Denis,
Thank for you suggestion of triggering the REST API via Build Configuration. Had not thought of that.
We are a .Net shop so here is the solution I am currently running with.
I then installed the console program on the build servers and rapped the call into Metarunner for ease of replication. The user password did not get copied well in the metarunner creatation process.
We use SVN so I don't know if my solution will work feature branches.