How to interpret build queue "Triggered By"?

When I see a job in the queue that has two build configurations separated by a semi-colon, I have been interpreting that to mean that the left hand config is the build that triggered this build and the right hand config is the initial trigger of the build chain.  Is that correct?

What does it mean if I have something like:

project B::configY  Triggered by ["project A::config X ; project B:: config Y, build #123"]

It seems to imply that I have a circular dependency.

17 comments
Comment actions Permalink

Here's a simple example of a triggering loop I continue to see in our build queue.  What can I be doing wrong in my configuration to make this sort of thing happen?
SnapShot.png

0
Comment actions Permalink

Hello Leon,

  What are Build Triggers which are configured for the "CI Build - corporate POM configuration"?

  I suppose that you might have a "Trigger by failed build" setting enabled for this build configuration.

  Kind regards,
  KIR

0
Comment actions Permalink

The corporate POM triggers are:

Build Trigger Parameters Description
VCS Trigger Watches for changes in dependencies
Quiet period: 300 seconds (default)
VCS trigger rules:
pom.xml
edit delete



The corporate POM build has no snapshot dependencies.

The dependent project, tvworks-server-parent, has the following triggers:
Build Trigger Parameters Description
VCS Trigger Watches for changes in dependencies
Quiet period: 300 seconds (default)
edit delete


tvworks-server-parent Dependencies:
Depends on Dependency options
CVS Common :: CI Build - corporate POM
Do not run new build if there is a suitable one
Only use successful builds from suitable ones
edit delete

0
Comment actions Permalink

Hello Leon,

  Given that VCS Trigger of configuration tvworks-server-parent has enabled option "Watches for changes in dependencies", you don't need a VCS trigger for corporate POM configuration.

  Please try removing this trigger.

  Regards,
  KIR

0
Comment actions Permalink

OK.  I haven't been able to find a description of this feature "Watches for changes in dependencies".  It's probably there somewhere, just haven't seen it.

I don't understand how this solves the problem.  I'm assuming it means build any dependencies if their source changes as well.  Sort of like a VCS trigger for the whole build chain?

Which build(s) do I need to enable this flag on if I have a complicated tree of dependent builds then?

0
Comment actions Permalink

Hello,

  If you'll have a complex graph and you'll want to build all corresponding parts of it on each change,
   you'll need only one VCS trigger on the top-most configuration (i.e. the one which depends on all other parts).

  It would be exactly as you name it - VCS trigger for the whole chain.

  Regards,
  KIR

0
Comment actions Permalink

We have many "leaf" node builds that depend on all other parts.  It sounds like we have to only have SCM triggers on those.  Correct?

In a direct chain of A depends on B depends on C, will a change to B avoid rebuilding C since C didn't change?

0
Comment actions Permalink

I'm also seeing Triggered By "Subversion" for projects but the project has no changes.  What does that mean?  Is this also caused by the superfluous VCS triggers?  It's part of a chain, but the dependencies indicate they were triggered by the "Subversion" triggered project.

SnapShot.png

0
Comment actions Permalink

What if you require VCS trigger exclusion rules in a dependency?  Removal of the trigger eliminates the possibility of fine tuning what source changes to the dependency's source base trigger the dependency build.

0
Comment actions Permalink

We have many "leaf" node builds that depend on all other parts.  It sounds like we have to only have SCM triggers on those.  Correct?


      Yes, it should work this way.

In a direct chain of A depends on B depends on C, will a change to B avoid rebuilding C since C didn't change?



      If only B was changed and there were no changes in C, it should take existing C build.

  Regards,
  KIR
0
Comment actions Permalink

Leon,

  If you have an enabled option "Trigger on changes in snapshot dependencies",
  VCS trigger settings in dependent builds won't work, unfortunately. The corresponding issue in our tracker is
  http://youtrack.jetbrains.net/issue/TW-11845

  Regards,
  KIR

0
Comment actions Permalink

Hello Leon,

  If you have enabled option "Trigger on changes in snapshot dependencies" for a configuration, and a subversion change is detected in one of the
  dependent configurations, the main configuration will be added to the queue as triggered by "Subversion".

  But when collecting changes for the main build, the corresponding change may be not shown if the main configuration doesn't have the VCS root
   with the subversion change.

  I suppose, this is what happens in your case.

  Regards,
  KIR

0
Comment actions Permalink

The requirement for a build to understand its position in the dependency graph (as a leaf or not) seems a bit onerous and on its surface looks like a calculation that could be easily made automatically by TeamCity.  It isn't always clear at the time of creation of a particular build whether it is the end-of-the-line for dependencies.  An example might be a web application that is initially distributed as a war but is later included by another department into an installer or app-server bundle.  However, if that's the way it works, we'll update our builds accordingly.

I think the only major problem that remains for us is why already built dependencies are no longer judged by our TeamCity instance as "suitable" for downstream builds.  Issue TW-17994.

0
Comment actions Permalink

Is this worth a feature request?  Triggered By for the "main" or "leaf" configuration should indicate which dependency build configuration VCS change triggered the enqueuing of the entire chain.  Especially if the changes list for the job can't reliably indicate this.

0
Comment actions Permalink

Hello Leon,

leon.franzen wrote:

Is this worth a feature request?  Triggered By for the "main" or "leaf" configuration should indicate which dependency build configuration VCS change triggered the enqueuing of the entire chain.  Especially if the changes list for the job can't reliably indicate this.


        I agree that the current behaviour is confusing. Please watch the issue I created: http://youtrack.jetbrains.net/issue/TW-18052

     Thanks!
     KIR

0
Comment actions Permalink

Since the trigger rules problem exists, I'd like to keep my SCM triggers in the dependencies as-is for now.  What ill effects can I expect from having SCM triggers for each dependency in additon to enabling "Trigger on changes in snapshot dependencies" for the leaf build configurations?

0
Comment actions Permalink

Hi Leon,

  In theory, there should be no practical harm. You may notice redundant triggered builds in the build queue,
  but these builds won't be run and should be merged with duplicates.

  Regards,
  KIR

0

Please sign in to leave a comment.