All VCS triggered builds for a build configuration are being flagged has "history builds"

We have a build configuration that represents a deploy to a development staging environment. It has a dependency on four other build configurations. It's also set up with a VCS trigger that triggers on changes in snapshot dependencies.

This was working great for some time now. We're currently running TeamCity version 9.1.5 build 37377.

Today we noticed that when this build configuration is triggered by a dependent VCS change, the dependencies build correctly, but the build configuration itself gets flagged as a "history build" (while running there's a warning icon that says "This build is outdated...", and in the history the build is grayed out and says "history" under the "changes" column).

As a result, on the project overview page, the build configuration keeps showing that there are pending changes for it.

Curiously, manually triggering the build configuration correctly treats it as a non-history build, flushing the pending changes.

I took a look at the teamcity-server.log and the teamcity-vcs.log, but nothing stood out at me.

Any advice on how to go about troubleshooting this?

3 comments

Hello Rafael,

A build can become history in several situations. Please check the full list. If you think that the build was marked as History incorrectly, then please attach screenshot demonstrating the problem and also screenshot of the Change log tab with "Show builds" option enabled.

0

Note that the project view shows that there's two pending changes for the "Deploy to Dev (S****** Tenant)" build configuration, one of which is for commit c2cc619ebe78

 

But the change log shows that while a build was triggered for c2cc619ebe78, it was flagged as a history build despite the fact that it was triggered a full day after the last time we manually invoked the build (we've been doing this because manually triggering the build gets treated as a normal build thus clearing the "pending changes" from the project view).

0

Digging into this further, I think the root cause of this is the way we're using the TeamCity feature that stores its settings in source control. Since we have multiple repositories, the TeamCity settings are stored in a repository dedicated to it.

While the "Deploy to Dev" build configurations were configured to trigger on dependent VCS changes, it didn't have a direct association with the TeamCity settings repository we had set up. As a result, when the build configuration is triggered via a dependent VCS change, it potentially uses an old commit from the TeamCity settings repository, which yields a "history build."

What makes this even more confusing is that if one were to change a TeamCity setting from the UI not related to the "Deploy to Dev" build configuration, the problem doesn't manifest itself since the "Deploy To Dev" build configuration will start referencing the newest commit in the TeamCity settings repository when it is triggered by a dependent VCS change. On the other hand, if one were to make a change directly related to the "Deploy to Dev" build configuration within the UI, "Deploy to Dev" builds that are triggered by dependent VCS changes don't use the most recent commit in the TeamCity settings repository, resulting in "history" builds. This made the problem seem to magically appear and disappear over time.

I'm not sure if the above behavior is intended. Is this a bug? Are we somehow misusing the TeamCity-settings-in-source-control feature?

We're ultimately trying to solve this by artificially attaching the TeamCity settings repository to the "Deploy to Dev" build configuration so that it can "listen" for changes in it, too.

0

Please sign in to leave a comment.