How to ensure sync at the same changelist number for dependent builds that sync from different Perforce servers?

Hello,

I have build C that depends on builds A and B. C does not have any VCS roots attached. A has 2 VCS roots that sync from Perforce server S. B has 2 VCS roots that sync from a Perforce proxy P that points to server S. Users may submit to either S or P. Build C has snapshot dependencies on A and B, but it only exists, so users may press Run button once to effectively run A and B.

It is absolutely critical that A and B run at the same changelist number when they run. Does my setup guarantee this behavior? Consider the scenario where both A and B go in the queue after being triggered, but only one agent is available, so A starts while B sits in the queue. Another change is committed at that time.

If not, what can I do to achieve what I need?

I could see attaching all 4 roots to both A and B, but the sync will be very, very long because P and S are in different physical locations as are build agents, and we are syncing ~10 gb each time. What if I add -:. checkout rules to the roots that I don't want to sync?

Thanks,
Oleg.

4 comments
Comment actions Permalink

Hi Oleg,

Actually, snapshot dependencies guarantee that different builds in the same build chain use the corresponding revisions from different VCS repositories.
It might be importnat what "corresponding" means here. At this time this means the revisions were latest in the repositories while TeamCity queried them one by one.
So I guess having snapshot dependencies is enough for the same revisions to be used in the absolute majority of the cases.
You can consider adding a check into the build and cancel/requeue the chain if they do differ.

0
Comment actions Permalink

Hi Yegor,

What about this scenario:

Both S & P are at changelists 123455.
User submits changelist 123456 into S.
P has not yet been made aware of 123456 (e.g. network issues).
Build C is triggered. The delay since 123456 is less than VCS checking for changes, so TC has not yet picked up this change.
I'm not sure when exactly VCS check occurs at this point. Maybe once A, B and C go in the queue, TC is going through VCS roots for build A, it picks up 123456 (from S). While it's going through VCS roots for build B, it picks up 123455 (from P).

Is this scenario not possible?
What I would be after is all builds running @123455 in this scenario since 123455 is the latest change present in both S & P when the builds were started. Do snapshot dependencies guarantee that to me? Thanks.

0
Comment actions Permalink

Hi Yegor,

Maybe I can simplify my problem a bit. What if S and P were completely independent Perforce servers and I want to use the same changelist number between the two builds? It does not really matter which server is used as the original. Let's say TC detects the changelist number in S for the build that uses S and I want to pass it to the build that uses P to sync at that number. So nothing to do with time of the scan of P.

0
Comment actions Permalink

Oleg,

TeamCity goes into the version control to get the revision for a build either when the builds are queued (when there are snapshot dependnecies), or when the build sarts (if no snapshot dependneices are used).

If S returns 123456 as the current revision and P returns 123455 at the same time, these revisions will be used correspondingly.

There is no dedicated way to start a build on a specified revision, nor there is a way to force the same revision number for different repositories. There is a related feature request, but the case of using the same number for different VCS roots seems too special to be supported as a dedicated feature.

The closest I can suggest is to use one VCS root in TeamCity and checkout the other on the same revision inside the build script. However, this way you will only get changes from the configured VCS root displayed in TeamCity UI.

Actually, I'd look for not TeamCity-related solution to the issue as TeamCity is most probbaly not the only client which need to check out the repositories. May be you can maintain a "master" Perforce server which will always have a consistent state and will be used for the clients which need this consistent state.

0

Please sign in to leave a comment.