Enforce revisions synchronization + Checkout rules problems with revisions used (v2020.1)

Answered

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!

2 comments
Comment actions Permalink

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

0
Comment actions Permalink

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

 

0

Please sign in to leave a comment.