Check-ins during build trigger unnecessary builds

Hi,

I have some builds that automatically update NuGet references and the final step of these builds check-in the updated Visual Studio project references.

When one of these build finishes and checks in, TeamCity detects another pending check-in which causes us some trouble. I have added a trigger filter to ignore check-ins made by TeamCity which works fine if taken in isolation, however the builds are apart of a project with several other dozen chained builds, and the pending changes have the effect that the entire chain is rebuilt when not needed, adding significantly to the overall build time (i.e. a couple of hours).


Is there a way that TeamCity can incorporate the changes checked in during a build as part of the same build, i.e. rebasing the revision to include the sources being checked in to avoid unnecessary builds from being triggered in snapshot dependencies scenarios?

Alex

6 comments

Hi Alex,

No, it's not possible to incorporate the changes checked in during a build as part of the same build.
Wouldn't it be an option to use VCS trigger rules checkout rules to filter out changes made by TeamCity?

0

Hi Alina,

if checkout rules supported filtering by user yes as these changes will not be detected as "pending" by TeamCity, but I don't see it as an option in the documentation https://confluence.jetbrains.com/display/TCD9/VCS+Checkout+Rules.

0

BTW, I have now tried specifyng a VCS checkout rule for a given user using syntax borrowed from the VCS trigger rules https://confluence.jetbrains.com/display/TCD9/Configuring+VCS+Triggers#ConfiguringVCSTriggers-VCSTriggerRules but it does not to work.

0

Sorry, I meant VCS trigger rules. Why they don't work for you? Please attach screenshot of configured VCS trigger rules and example of the change you'd like to filter out.

0

As I mentioned in my first post I am already using a VCS trigger rule. Having this rule helps avoiding the build from getting triggered again and again, but my problem is different.

Because this build is part of a build chain and because it updates and checks-in files when NuGet updates are available (which happens fairly frequently), the build will result in new pending changes, therefore if other builds along the build pipeline get triggered, this build will also be triggered due to the pending changes caused by it's previous run!

Here's a simplified explanation of the various steps involved:

1) Developer Bob check-ins fix to Component A - revision 1111
2) Build A detects a pending change (revision 1111 from Developer Bob) and gets triggered
3) Build A checks if newer version of referenced NuGet packages are available, if there are NuGet updates it will update those references and check-in the updates project files - revision 1112
4) Build A detects a pending change (revision 1112 from Build Agent account) and does not get triggered because of the VCS trigger rule
5) Developer Tim check-in fix to Component B - revision 1113
6) Build B detects a pending change (revision 1113 from Developer Tim) and gets triggered
7) Build B has a snapshot dependency on Build A, because Build A has a pending change (revision 1112) it gets run even if the existing build can be re-used as it has all the necessary changes already

In our real life scenario our project has approximately 70 builds concatenated in build chains, and the above can result in significant overhead (several hours) during our builds.


The ideal fix for this is that Build A at step 3) would show as including changes from both revision 1111 and revision 1112, rather than detecting revision 1112 as pending changes.

0

Please sign in to leave a comment.