Downsides of not ticking "Trigger a build on each check-in"
Answered
I've always ticked this box, since the documentation says "ensuring that no other changes get into the same build" which sounds like something I should be worried about.
But as the project has grown, the builds can take hours, all queued up.
What's the point of this option? What is actually meant by "ensuring that no other changes get into the same build"? If I untick the optin, what could possibly go wrong?
Thanks.
Please sign in to leave a comment.
Hello Luke,
If "Trigger a build on each check-in" option is enabled a build is triggered for each revision.
If you uncheck this option then several check-ins can be included in one build. For example if there are three pending changes in the build configuration, when the build started it will include these three changes and also check for new changes. You can specify how often TeamCity polls VCS for changes using Checking for changes interval and configure an acceptable interval between changes using Quiet Period in VCS trigger. It tells VCS trigger not to trigger build immediately after the change is detected but instead wait for some time. If within this period another change appears VCS trigger will wait this period of time again.
Also you can enable "Include several check-ins in build if they are from the same committer" option, so changes will be grouped by user and build will have single user changes only.
Thank you, Alina. Pretend for a moment that I have never used this option, what would be the benefit of turning it on?
Bump.
Sorry for delay. If you turn "Trigger a build on each check-in" option on you'll have a build for each check-in. This helps to figure out the exact change that broke a build or caused a new test failure. However it will lead to an increase in the number of builds. You can use this option if you have fast builds and enough build agents.