Not latest revision of branch is builded Follow
I use TC with git. The following features are used for VCS:
- branch specification `+:refs/heads/*`
- only checking out a part of the repository via checkout rules: `+:commons`
So the problem now is when e.g. the branch `device-modifiers-core` is builded (via VCS trigger). Instead of taking the head of the branch, it seems that a older commit is used. In TC i get the following:
[17:01:15][Compute revision for 'smec-services'] Upper limit revision: 4dcfd2cd64bb81f2d0e84ed6c7ff9c9458afe07b, maxModId 29765
[17:01:15][Compute revision for 'smec-services'] Latest commit attached to build configuration: 8b9862db1ef9d8a8f37b9bb9af0e92d47f05194b
[17:01:15][Compute revision for 'smec-services'] Computed revision: 8b9862db1ef9d8a8f37b9bb9af0e92d47f05194b
In this case, `4dcfd2cd64bb81f2d0e84ed6c7ff9c9458afe07b` is the correct head, but I have no idea why the commit `8b9862db1ef9d8a8f37b9bb9af0e92d47f05194b` is even showing up in here, because this is just the commit of a older tagged version of the master branch.
What does this `computed revision` means and why is it taken in favour of the head of the branch?
Please sign in to leave a comment.
witnessed teams run CLI build steps with `git fetch` or `git pull` commands at the start to get around these issues of correct commit calculation.
We understand the issues this problem has, and we work constantly and actively on trying to ensure that the correct revisions are built, but under very specific circumstantes it becomes a non-trivial task. This issue has multiple possible different causes, not just one, so we recommend that new instances are posted separately if you face them, as we can treat them separately.
Furthermore, this current issue is being discussed with the developers directly tied to the involved subsystems in the issue that Kuan posted (https://youtrack.jetbrains.com/issue/TW-62111), so if you face this issue and consider that it is the same, we would recommend you add a comment to it providing the adequate details (where the commit comes from, whether it is regular or merge, special type of merge, how the build is triggered, etc.). That will be a more productive way of getting it fixed faster, as the dev team will have direct access to the information they need to fix it.
Hope this helps clarify our situation on this issue.
Is there a new URL to view https://youtrack.jetbrains.com/issue/TW-62111
I'm getting a 404.
the link to the bug is broken.
Hello Edward, Tomer,
Sorry for the delayed response here; the issue had limited visibility so I have just updated it for public access. Could you please share the details of your case on the bug page?
Still seeing this issue on 2021.1.1
This "fix" of deleting the VCS root and recreating it worked for us as well.
I've encountered the same problem here. The VCS detach & reattach workaround somehow circumvents what's blocking it from checking out from the latest revision.
As to my particular case, the issue comes from deleting and recreating a branch from which the package has been built once. My thought is the "branch unique identifier" Tenacity had from the previous builds is no longer applicable for fetching the latest revision for that branch, after the very same branch was recreated in the remote GIT server.
I would like to share the solution that solved the problem in my case.
There were partial checkout rules in `Version Control Settings` of the build. This caused wrong revision to be calculated.
Replacing the rules with the full check-out (e.g., "+:. => FolderName") solved the issue.