Search code examples
teamcityteamcity-10

How to make Team City check out the latest revision of a branch - regardles if a tag exists

For some reason, TC is no longer detecting changes to the development branch after we tagged a release. Up until last Friday, there were no tags, and TC had been building fine up until that point. We then added a tag to mark the end of a spring and following that, no changes are picked up by Team City. Triggering a manual run only checks out the same revision that was tagged. I don't see why tagging a release should affect the VCS procedure, given that nothing change there.

Relevant output from build log

[10:18:29][Compute revision for 'app-develop branch'] Upper limit revision: 1ec51e6c701548753678c18c20e24c87a6c189f7
[10:18:29][Compute revision for 'app-develop branch'] Latest commit attached to build configuration: 1ec51e6c701548753678c18c20e24c87a6c189f7
[10:18:29][Compute revision for 'app-develop branch'] Computed revision: 1ec51e6c701548753678c18c20e24c87a6c189f7

When I manually ssh into the CI server and go to the build directory I see that the remote develop branch can be seen, but the local is not updated:

* cf2c86a - (origin/develop) Handle special users when formatting names (67 minutes ago) <Carl-Erik Kopseng>
* 70cadf0 - Fix bug in formatting (82 minutes ago) <Carl-Erik Kopseng>
* 8f24c0d - Move user formatting util over to domain class (83 minutes ago) <Carl-Erik Kopseng>
* 1ec51e6 - (HEAD, tag: sprint-15-demo, develop) Merge pull request #826 from mycomp/nim-605 (7 weeks ago) <Carl-Erik Kopseng>

config

trigger section

Solution

  • I'll add another answer, as the one by @Amy seemingly worked in one situation, but not for another project. This other project already had the default branch set to the right (default) value of refs/heads/master.

    What finally worked for me was the tedious solution found on the TC community:

    • Detach the existing VCS root
    • Create a new one with the exact same settings

    Yes, that shouldn't make a difference, but it did.

    I suspect the joker of the puzzle might be that we reverted back to a previous configuration last week. That made the build counter incorrect (DB vs config), which might have fuzzed with the concept of historic builds and all that jazz. In any case, certainly a bug from the user perspective.