What is the difference between snapshot dependency and finished build trigger in TeamCity?

Question

It appears to me that the function of snapshot dependency completely supersedes that of finished build trigger in TeamCity. Can anyone explain more the effect of these methods if they result in different chain behaviour? As an example, if I had a build chain of A->B

Does the chain actually behave any differently between these three setups?

• Setup 1: Single finished build trigger of A in B.
• Setup 2: Single snapshot dependency of A in B.
• Setup 3: Both finished build trigger of A AND snapshot dependency of A defined in B.

I understand that one can kind of treat Snapshot Dependency as "AND" operation of all the dependees, while Finished Build Trigger works like "OR" operation amongst the dependees. But in the context of a sequential chain, is there any difference?

Thanks, Scott

Answer 1

A "Snapshot Dependency" and "Finished Build" trigger are very different. one is basically a "push" operation while the other is a "pull" operation, respectively.

Setup 1: If I have build configs A and B where B has a "Finished Build" trigger on A, then the opposite behavior is true. Triggering B will have no affect on A, but triggering A will effectively trigger B once it has finished.

Setup 2: If I have the exact same setup but instead B has a snapshot dependency on A, then whenever B is triggered, A will run first, or at least check to see if it needs to run, before running B. IF only A is triggered, then B will not be triggered.

Setup 3: Setup 3 is slightly different because it doesn't JUST depend on the "Finished Build" trigger or the snapshot dependency. it ALSO depends on the initial trigger (VCS, scheduled, or whatever). for example, if you have a VCS trigger on A, and B has both the "Finished Build" trigger and "snapshot dependency" on A, then you effectively get the behavior of Setup 1. A will get triggered on VCS changes and B will be triggered AFTER A (using the same snapshot). In fact, without the snapshot setup, it is not guaranteed that B will use the same snapshot as A, which may or may not be what you want.

So in general, when you want a "left-to-right" trigger process, you use BOTH finished build triggers and snapshot dependencies to guarantee the sanctity of the build collateral.

If, on the other hand, you have your initial trigger (VCS or scheduled or whatever) setup on B, then having the "finished build" trigger is somewhat nullified, because B will always be triggered first (but not run), and then it will trigger all of its dependencies and automatically run after they finish.

hope that helps. thanks!

Answer 2

As you said, there's a big difference if a config snapshot-depends on multiple other configs (Z snapshot-depending on both X and Y). But you're not interested in that...

It's true to say that in the trivial A->B scenario Setups 1 .. 3 are close to equivalent. Of course, only if the events that trigger A and B are one-to-one (e.g. both A and B are triggered on the same VCS root; or they use different VCS roots but are only triggered manually). If this is true, then your A->B chain is super-trivial and might be possible to implement within a single build configuration.

Other subtle differences that come to mind:

1. Passing parameters down the chain.

   • Suppose A and B share some user-defined parameter "foo". The A->B snapshot dependency lets you define %foo% in A and reuse it in B using %dep.A.foo%. That's really convenient because you don't need to worry about keeping the value of %foo% in sync between A and B.
   • Now suppose that you want to manually trigger the A->B chain with a custom value of %foo% (you'll specify the value in the "Run..." dialog).
   • Since TC cannot pass the value up the chain (from B to A), you must really trigger A and specify the custom value there. When A finishes, it will trigger B, which will overtake the custom value. That's Setup 3.
   • You can't achieve the same with Setup 2, i.e. by triggering B with the custom value. The custom value would have no way of getting across to A.

2. Scheduling.

   • Suppose you have a scarce resource, and B cannot possibly run for every commit. You end up with each run of B "containing" (covering) multiple VCS commits. At the same time, A has no problems running for every commit.
   • In Setups 1 and 3, if you have a VCS trigger on A, you'll end up with
     • a run of A for every commit
     • a run of B with "aggregated" commits (each run covering multiple changes)
   • In Setup 2, if you have a VCS trigger on B only, you'll end up with aggregated commits in both A and B. Which may or may not be what you want...

3. Different VCS roots.

   • If A and B have different VCS roots, then Setup 1 (with VCS trigger on A only) and Setup 2 (with VCS trigger on B only) will behave quite differently.

In general, I agree the "pull" nature of snapshot dependencies (Setup 2) is much more appealing. Combine with the trigger if needed (Setup 3).