Not latest revision of branch is builded

Hello,

If checkout rules are configured then not the latest revision can be used. If you check out only some path of the repository, the revision used by the build (and displayed in revisions table on Change tab of a build) should correspond to the latest commit which changed the content of the checked out path. If there were changes which do not change the content being checked out, those should not appear in the build's changes and should not affect the build's revision.
However, there are several corner cases related to recently attached/edited VCS roots and also to merge commits. Is it your case?

HI, I am affected by those merge commits you're talking about.
But this only happened after migration from a SVN repo. I can't reproduce it now. So lets say everything is ok. I will inform you if this happens again reproduceable.

Hi Alina,

we are also having same issue with our TC, it is cloning old commit but not the head revision. Following is what we are seeing in TC logs.

[12:52:01][Compute revision for 'TEST 2014'] Upper limit revision: 3af12e6b236e
[12:52:01][Compute revision for 'TEST 2014'] Latest commit attached to build configuration: 6836930d9c25
[12:52:01][Compute revision for 'TEST 2014'] Computed revision: 6836930d9c25

We do not have any checkout rules that restricts the part of the code and this issue is not consistent to reproduce. But it looks like to me that it is happening when there was merge in the code, I might be wrong. Can you please explain why the Computed revision is different than Upper limit revision?

 Thank you

We have exactly the same problem without any checkout rules. We use git tag, let's say r91.0, but the computed revision is totally wrong, is it a bug of teamcity? Below is an example, the correct revision is r91.0 (7a38ca124473c3dcb2631661e026652c39e12762), but the computed revision is wrong:

We still experience this problem: 

1) new branch is created and pushed with some changes
2) -> VCS Trigger works and creates new build
3) master is merged into branch
4) -> VCS Trigger doesn't trigger build
5) -> No VCS changes are displayed for the build
6) -> when build is manually triggered, the correct revision is taken from GIT

Note that we use GIT checkout rules where we only checkout a certain folder and not the whole repo.

It happened to me a couple of times. Seems that in some conditions teamcity gets stuck with some old revision. Two workarounds worked in my case:

1. Either clear checkout rules, run a build and restore checkout rules.

2. Create a copy of the whole build configuration and replace the original one.

I happened several times, finally we have to add additional scripts to each of our projects to check SHA. Really strange.

The original question is answered, but people experience similar problems. It would be great to have detailed description of the logic behind 'Latest commit attached to build configuration'. How is this commit evaluated? In which circumstances it is not equal to 'Upper limit revision'?

The issue I have been facing since June 2017 is now fixed in Teamcity 2017.1.2.

https://youtrack.jetbrains.com/issue/TW-49281

I too, am having this problem after upgrading to 2017.2.2 a few days ago.  My symptoms are:

- VCS has a checkout rule to ignore everything in the repo (dummy checkout basically just to get the hash for commit statuses)

After removing the rule and allowing it to checkout files, it works fine, but it's not ideal in my environment.

UPDATE: it still happens regardless of the rules

We have the same issue on 2017.2.

We don't use checkout rules.

Can we have a parameter, which disables this logic and the latest commit is always used?

Hi all,

For those of you who want to disable history builds entirely at some level, please refer your comments to: https://youtrack.jetbrains.com/issue/TW-18651

History builds should be tagged appropriately under determined circumstances described here https://confluence.jetbrains.com/display/TCD10/History+Build, or it might lead to other issues (for example, artifact dependencies that pull from the last build might pull from an old one instead of the actual most recent one), so it's not a high priority, but if you would like to see it implemented, your comments will be read there, here they won't add to the discussion.

Why builds are sometimes incorrectly tagged as history is usually a different case for each scenario. We are very likely going to need to investigate them on a case by case basis, if your scenario is not covered in the documentation linked above, please report it to our tracker: https://youtrack.jetbrains.com/issues/TW, as it might actually be due to a bug that we need to fix.

Still seeing this issue on 2017.2.3.

Only thing that solved it for us was deleting the VCS root and recreating it (we did so with a different ID just in case). This a tedious solution tho since you have to go into each build configuration using the root and detach it before you can delete it.

Thanks, @Travis, for that brief comment on recreating the VCS root. I had the same issue and that fixed my problems after all other failed. Posted the answer to Stack Overflow for good measure :)

Same for us, VCS duplicate helped (as far as I remember).

I've run into this and 'resolved' it by making sure the default branch in VCS Settings is set to a simple name like 'master' instead of using 'refs/heads/master'. While specifying other branches to monitor as `+:refs/heads/*`

@Leonard, that is just too funny, as one of the two times this occurred to us we changed it from "simple" names to the more complex ref spec. Which just further strengthens the notion that this has nothing to do with the refspec and rather some bug underlying the whole thing.

@Carl-Erik We've just seen same occurrence as well with the VCS changed as I previously suggested!

Looking closer at the issue we notice it's predominantly happening when someone tries to build a branch that just had a merge from master into it so you end up with a commit with 2 parent commits. I reckon if that hash from the master branch contains changes that are newer than the branch changes it seems to favour the master branch hash over the feature branch hash that was created as result of the merge. In cases I looked at there seemed to be slight timely contention in this area.

Simple solution is to either make a small non-functional commit and run a build again against the branch or update from master branch again (which has a risk of repeating the issue again, depending on how busy your integration is into master).

Another approach on other projects we've taken is to additionally monitor `+:refs/pull/*/heads` instead of `+:refs/heads/*` as that will give us the pre-merge PR state of a branch, which is very nice for PR builds and deploys.

This is still an issue in TeamCity 2019.1.2. During checkout step of our build, TeamCity is opaquely choosing an older revsion.

I have confirmed again that deleting and recreating the VCS root resolves the problem, but I cannot understate how painfully slow this process is.

The git repository we are pulling from is not using any branching; it's all trunk-based development. So, there shouldn't be any merges tripping up the checkout process.

Modifying the refspec did not help.

Hi Travis,

your situation seems particularly strange, as most of this scenarios happen when branches are involved. As I mentioned in my last comment (https://teamcity-support.jetbrains.com/hc/en-us/community/posts/205450530/comments/360000147244), this scenario does not have a single common root and having history build, even automatic ones is a feature, is something that has uses and valid scenarios for it, so identifying why it misbehaves beyond the basic points described in the docs linked in that comment requires to check on a case-by-case basis. In particular if you have just a single branch, please collect:

-VCS (commit) history of the related branch

-Screenshot of the vcs root configuration

-build log of a build that was tagged as history due to loading an old commit

and post them to our tracker (you can set the attachments to be private). There we'll be able to investigate deeper what and why it's happening in your scenario.

I have gathered those items, but I do not see how to set the attachments to private.

Hi Travis,

thanks for it. Once you upload a file while creating the issue, you can hover over the file, and a few icons will show up. The one with the pencil is edit, where you can select the visibility of the attachment. Set it to jetbrains-team and yourself to make it only visible to your selection.

I do not see any icons when I hover over images I try to attach in this comment.

Hovering over the attachments should show this:

Does it not for you?

No, I don't see any icons.

Hi Travis,

I'm sorry, I missed the notification for your last message. As I mentioned, this thread is not the place to discuss individual instances of the issue. I requested that you use our tracker for it: https://youtrack.jetbrains.com/issues/TW. There is where you can set the attachments to private, the forum is public and we do not provide a way to post private information here as of now.

It's now 2020 and this issue still hasn't been fixed since 2016. Will it ever be? We can't trust tests run through TeamCity anymore as we aren't sure whether we have false negatives or false positives. And how can we release builds which might compile fine but use code from different branches?

It literally requires every build to be verified manually. This is not acceptable. It makes TeamCity very high cost. We may be looking for alternative CI/CD tools if this is not fixed.

https://youtrack.jetbrains.com/issue/TW-62111

I am really upset that this issue persists for such a long time, you have just cost me money. I will have to look to change platform.