Schedule Trigger does not run when there is a dependency (Do not run if suitable exists)

I added dependencies between my Build Configurations, and since then the Schedule Trigger is aborted for some of the configurations.
Here is a model of the problem:

A has a Snapshot Dependency on B,
  -CHECKED - Do not run new build if there is a suitable one
  -CHECKED - Only use successful builds from suitable ones

A and B have a Schedule Trigger to run every 2 hours

There are no check-ins in source control
At the 2 hour mark, A is queued once, B is queued twice, A runs and B never runs.

If "Do not run new build if there is a suitable one" is not checked then B also runs
It seems like the dependency rule is canceling the schedule build for B.

Is this an expected behaviour?

I would like B to build with the Schedule Trigger, but avoid building it every time A has some change checked in.


UPDATE: This dismissal of build B does not happen when I click the Run button on A and then B. While A runs, B is queued twice, one of them goes away but the manual Run still runs. Why is a Schedule Trigger different than this?
1 comment
Comment actions Permalink

Hi Paulo,

Thank you for the detailed description. It's an interesting case.

Actually, the behavior seems to be a consequence of these two loigcs in TeamCity:
- when two builds appear in the build queue at the same time and they are "the same" (in terms of changes and no customizations), TeamCity merges them into one.
- when queued build of B snapshot-depends on queued build of A with "Do not run new build if there is a suitable one" optino ON and there is a finished build  which is "the same", TeamCity drops the queued build of A and uses finished build of A as B's dependency.

By their own they are OK, but in your case they produce somewhat different results.

This seems to be a minor issue with a workaround to make B start later then A, but I filed the case as so that we have it "documented".


Please sign in to leave a comment.