snapshot dependency recommendation


I wanted to check to see if the documentation for snapshot dependencies is correct?

In the second row where it talks about parent and child it seems wrong I would expect the parent to be the top of the build chain if this is the snapshot build dependency chain C -> B -> A (A would be parent).  Am I reading the documentation correctly?

To clarify how snapshot dependencies work, C,B,A build configurations in my example all use the same vcs root.  They take different flags to run more tests.  If there are pending changes A will build first in this chain because there is a snapshot dependency throughout correct?  What should I setup for build triggering if I want A to be the start of the chain?  Currently we are using the build triggering like so if A is successful B will run, if B is successful C will run.

With this setup if there potential for C to not trigger for awhile if B is running and more changes come along will it go back and build A then B again before running C or will it build C directly after B runs?


1 comment
Comment actions Permalink

From my testing I think the optimal configuration and what I'm looking for is to have the following snapshot dependency chain C -> B -> A, then set C to have a VCS Trigger since they all share the same VCS Root.  If something is checked in C triggers but since there is a snapshot dependency it goes up the chain and then A is triggered first and they are all put in the queue at the same time.  While B is running and I checked something in I observed the behavior of when B was done C C then ran and the new checkin was part of another build chain.  I did however observe a different behavior when setting the vcs trigger on A instead and having C trigger on a successful B and B trigger on a successful A.  What I noticed is when I checked in when B was running A queued up and since C only triggers on a successful B it wasn't in the queue yet thus A ran with new changes before C could run.


Please sign in to leave a comment.