Snapshot Dependencies: Shouldn't suitable builds also pay attention to the Run on Same agent setting

We are having situations where Build Queue entries are showing up with a Time to start of ???.

After investigation, it appears the following is happening:
     Assume a build "Final" has a dependency on "Dep1" and "Dep2".  Both dependencies have the following dependency options: Do not run new build if there is a suitable one, Only use successful builds from suitable ones, Run Build on same Agent
     "Dep1" can run on either Agent1 or Agent2, it just so happens to have last run (successfully as build 1) on Agent1 with the current source.
     "Dep2" can run on either Agent1 or Agent2, it just so happens to have last run (successfully as build 1) on Agent2 with the current source.
     "Final" is manually triggered.  Then I go to the build queue, the build queue show it as Time to start ??? with the message that it is waiting for its snapshot dependencies to build..  When I find the relevant entry in Build Chains, it shows that it chose to use the build 1 of Dep1 and the Build1 of Dep2 as its "suitable builds".  However, these two builds do not set up a state where "Final" can actually build, so we end up in a situation where the build will never run.

Note that our actual situation is somewhat more complex in that the conflicting dependencies are actually well down the transitive chain, but this description should get the idea across.

When I look at the relevant documentation for "suitable builds": https://confluence.jetbrains.com/display/TCD9/Snapshot+Dependencies#SnapshotDependencies-SuitableBuilds  I see that it is behaving exactly as documented since the suitable builds evaluation pays no attention to the Agent that ran the candidate build.  Thus I cannot call this a bug.  However, can anyone explain why this would be desired behavior?  Shouldn't Suitable Builds evaluation occur after a target agent is selected, or at least be reevaluated after a target agent is selected in situations under which Run on Same agent is set?

2 comments
Comment actions Permalink

Hi Todd,

We have the related issue in the tracker: https://youtrack.jetbrains.com/issue/TW-17561. Please watch and vote for it.

0
Comment actions Permalink

I agree that fixing that issue will almost certainly resolve mine.  They are not quite the same because there was nothing manual that created ours.  The bad situation was created entirely by TeamCity.  All 3 builds are configured to be able to run on either agent, but the final one happens to require both of the others to have also previously run on its agent, so only one of the dependencies can really be suitable, and the other should have been queued to run just like any other unsatisfied dependency.  TeamCity's automation completely setup this situation where the currrent "Suitability" code made it impossible to continue without explicit manual intervention (to force one of the Dep products to run on the other agent).
I have followed your advice and voted up that issue.

0

Please sign in to leave a comment.