Wrong build number order on TC
Completed
Environment:
TeamCity Professional 2019.2.2 (build 71923)
Screenshot:
Notice we are looking at build 1357. And yet 1351 is shown as a newer build. This is not a one off case. Even "Overview" tab for build 1351 shows build 1356 as older.
The only significant input I feel worth sharing is that build 1352 was cancelled by a user.
Please sign in to leave a comment.
I meant that I cannot think of anything relevant to share. However, if more inputs are needed, I can share.
Seeing the "build is outdated" messages too as described here: https://teamcity-support.jetbrains.com/hc/en-us/community/posts/115000783390-Outdated-builds.
1 day later, TC did more builds and fixed those links. Not sure what was wrong yesterday. But now a newer build is correctly identified.
No longer following up.
The order in which previous/next build are reported is determined by the revision first, then by the timestamp of build. For the history build on your screenshot, this could affect the build`s previous/next build ID because of revision being in between of two existing builds. See the details on history builds at https://www.jetbrains.com/help/teamcity/history-build.html
In regards to the builds being reported as outdated - this warning will appear whenever you have a build running while there is a newer revision finished build.
In case the issue occurs again and builds in question would appear to be false-tracked as historical, please share the revision of last historical build, revision of last non-history build of same branch and revision tree to check against. You could do so in a private manner via "Submit a request" form.
Fedor, I did read that page already. It does not clarify what a "newer revision" means.
It will really help to provide examples for some VCS backends. For example, in git, a newer commit can mean chronologically newer ... or ancestory wise newer.
No longer affected by the problem. Just an opportunity to improve otherwise abstract documentation with practically useful examples.
This is a good point - thank you for bringing it up! We are going to update the corresponding documentation articles shortly; for now, let me respond with the clarification from development team:
For any VCS root, we do store the commits as they are being reported by the version control server; for each commit, there is an internal ID which grows in a monotonic fashion. When we want to compare two revisions, this boils down to comparing their IDs - in this scheme, history build is any build which is based off a revision with ID less than the newest.
For a case when there are multiple VCS roots present, the logic is similar - we do always have a single maximal ID across all of the commits under the build configuration and its VCS roots. There is a request to change this behaviour, so that, for instance, Git graph would be taken into consideration instead of ID-based compare.