Enforce revisions synchronization + Checkout rules problems with revisions used (v2020.1)
Hi,
I just noticed a certain behavior which I don't know if is intended, but at least intuitively seems like quite a problem
Example - Part 1
Repo - contains folders F1 and F2, last revision is R10, but last revision when limited to F1 is R5
Configuration A - Checkout rules: -F2; VCS Root 1
Configuration B - Checkout rules: none; Depends on A (Enforce revisions synchronization = true); Simplest VCS trigger - just vcs { }; VCS Root 1 (same as A)
Build A1 of configuration A sees latest revision as F5
Build B1 is triggered with revision F5
I would assume A1 would use F10, but although inconvenient this is still understandable
Example - Part 2:
We continue with the setup from Part 1 except we change B->A dep. Enforce revisions synchronization => false
Build A2 of configuration A sees latest revision as F5 (nothing new)
Build B2 triggered automatically uses revision F5 <-- this should be flat out wrong
Build B3 triggered manually uses revision F10
B2 and B3 consume the same dependencies
Is this a bug? If not, is there some logic behind this?
Is it possible to use the latest revision in a branch even when using Checkout rules?
Thank you!
Please sign in to leave a comment.
Hi Jiří,
I would like to understand the exact sequence of actions to reproduce the issue:
Could you explain how exactly you trigger the build when you start it manually? Which build it is, A or B?
When the builds are triggered automatically, do you commit a change to the VCS to start it off? If so, which files do you modify?
Enforce revisions synchronization will only have an effect when you promote an existing build of configuration A to configuration B.
In 'Example - Part 1', build B1 should use F10. In 'Example - Part 2', build B2 should also use F10. A possible reason why it didn't could be that the F10 change wasn't detected yet. Please verify that.
Regarding always using the latest revision with checkout rules, you cannot make TeamCity always show the latest revision on the changes tab in such case, sorry. But you can still access the latest revision via a parameter if you need to. Please refer to this comment for the explanation.
-Anatoly
Thank you for reply
All triggers are on B. A triggers via Snapshot dependency.
Yes, it's via VCS changes, those particular files were included in folders visible to B, but excluded by Checkout rules for A.
The changes were already detected, because based on that TeamCity triggered the build of build configuration B. The correct Git hash was also listed in B's build log, but (if I understand it correctly) its snapshot dependency A only saw previous revision (because the newest revision modified files outside of A's checkout rules) it made B use the previous (not latest) revision too.
By "TeamCity always show the latest revision on the changes tab" you also mean "fetch latest revision for build"? I'm OK with not seeing it listed in Changes, what's important for me is that correct revision is taken.
More specific example:
Repository:
- Sources
-- Program.cs (added in Revision R1)
-- Tests.cs (added in Revision R3)
- E2E
-- RunTestSuite1.bat (added in Revision R2)
-- RunTestSuite2.bat (added in Revision R4)
Build A - Compile sources -> Checkout rules only for Sources
-> step 1 = compile .cs files
Build B - Run tests -> No checkout rules, SDependency on A
-> step 1 = run RunTestSuite1.bat; step 2 = run RunTestSuite2.bat
After committing R4 TC triggered B, but since A only sees R3 because R4 is not in Checkout rules ... and consequently build of B uses R3
(Upper limit revision is R4, Latest commit attached to build configuration is R3, Computed revision is the same and therefore R3)
And fails with file 'RunTestSuite2.bat' not exists, because it was committed in R4
This configuration is question does not use versioned settings in VCS
At least that's how it seems to me, maybe I'm misunderstanding something. But we definitely have fails on non-Historical builds about missing files that are actually there (if TC were to fetch actually latest sources), last one just 15min ago (the allegedly missing file has been there for 1 month, plenty of time to notice)
Hmm, I'm not sure if this information helps though
Hey I think I saw the same issue and instead of using Checkout Rules I think we both should use the VCS Checkout Mode instead to then modify what actually gets checked out.