Trigger child build with the same sources

Hello

I have a question on snapshot dependency.

Build A - has a vcs trigger, is triggered on VCS changes.

Build B (same vcs roots as A) should start after A completes successfully,and should run with the same sources as A. If I set up a snapshot dependency on B (to get the same sources as A), B in turn triggers A. That is not the desired behavior that we are looking for. Build A has to trigger B on successful completion (of A) and B should run with the same source revisions as build A. Is this kind of configuration possible with TeamCity? I know that triggering B on vcs changes (instead of A) and then adding a snapshot dependency on B is a possible solution, but A is the master build and we need A to be triggered on vcs changes.

TeamCity Enterprise 4.5

Thanks

9 comments
Comment actions Permalink

If B should be started after the A then B depends on A, and you can add snapshot dependency from B to A. If you also need to trigger B when there are changes in A you can add dependency trigger (in fact you already have one).
With such setup when build B is added to queue, A will be added too. But if you enable option "Do not run new build if there is a suitable one" in the snapshot dependency then TeamCity will search for existing build of A and if such build is found, A will be removed from the queue and won't start again.

0
Comment actions Permalink

Thanks Pavel

What if, by the time B is triggered by A, there are pending changes in A?

Consider the following scenario

1. User checks in changes to vcs (shared by both A and B), A starts running (A1)
2. User checks in changes again, A is triggered and placed in queue(A2)
3a. A1 finishes running, B is triggered(B1) and placed in queue, but by then A2 has already started running.
or
3b. A1 finishes running, B is triggered, but there are pending changes, so B triggers A (A2)

Would B1 wait until A2 is complete or would B1 run with the same revisions as A1?

0
Comment actions Permalink

When B is added in the queue, all builds it depends on will be added too. Then TeamCity performs changes collection for B and after that decides whether some builds can be removed from the queue and replaced with started or finished builds. If A2 will still correspond to B by changes then A will be removed from the queue and B will depend on A2 and will stay in the queue till A2 finishes.

In 3b scenario additional build of A will be started because B contains more changes than A1 and a new build of A is needed to satisfy snapshot dependency requirements.

0
Comment actions Permalink

Thanks again

We are trying to avoid exactly that. We are looking to run B after every successful build of A (with the same source). So in the above scenario, we would like B1 to take the same source of A1and run immediately after A1 (instead of waiting for A2 to complete) regardless of whether there are pending changes or not. From what I am hearing I am guessing that kind of configuration is not possible with TeamCity?

0
Comment actions Permalink

If B and A use the same VCS root you can have a snapshot dependency from B to A and drop dependency trigger at all. Then enable VCS trigger in B. In this case you will probably have the configuration you need.

If a change occurs, B & A will be added into the queue and B will start on the same sources as A after the A finishes.  If someone triggers A build, build B won't be triggered. But if then B is triggered it will either reuse existing A build or trigger new build of A (depending on a snapshot dependency settings and availability of new changes). Is this a desired behavior?

0
Comment actions Permalink

Thanks Pavel

I mentioned in my original post that adding a vcs trigger on B is an option, but since A is the master build, we are trying to avoid that.

Setup : vcs trigger on B, snapshot on B to A (do not run if there is a suitable one)

1. User checks in changes to vcs
2. B is triggered (B1), which in turn triggers A (A1) and placed in queue
3. A1 starts running
4. User checks in changes to vcs

In the above scenario, would B1 run after A1, or would another build of A gets kicked off since there are pending changes when B is about to run?

0
Comment actions Permalink

In this scenario when next change occurs, B2 & A2 will be added in the queue. And B1 will be started with A1 sources.

In 4.5 version there was an issue with a bit greedy queue optimizer (optimizer is an especial service which removes builds from the queue if there are other builds containing more changes). So in 4.5 in this scenario build B1 could be removed from the queue by optimizer because B2 contains more changes. This behavior is fixed in 5.0.

But anyway if B1 starts it will use A1 sources, if B2 starts it will use A2 sources. Snapshot dependency requires sources synchronization, and this is what TeamCity will try to achieve in this case. BTW if you have enough agents it is possoble that A1 & A2 will run in parallel. If this is undesirable, see "Max running builds" option at the general settings page.

0
Comment actions Permalink

Ah, thanks, that explains a lot. That is exactly what is happening on our TeamCity instance, the optimizer kicks in and keeps triggering A until there are no more pending changes. Unfortunately, running in parallel is not a viable option for us at the moment.

Is there a feature request already for implementing the configuration I mentioned in my original post?

ie have B run after every successful build of A(even if there are pending changes), with the same source as A. (vcs trigger on A). Or in other words, each successful A should have a corresponding run of B.
0
Comment actions Permalink

I do not remember such a request, feel free to submit one. But please provide a real use case why do you need this feature, because at the moment I still do not understand why you can't use snapshot dependencies.

0

Please sign in to leave a comment.