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.
Please sign in to leave a comment.
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?
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
The corporate POM triggers are:
Quiet period: 300 seconds (default)
VCS trigger rules:
pom.xml
The corporate POM build has no snapshot dependencies.
The dependent project, tvworks-server-parent, has the following triggers:
Quiet period: 300 seconds (default)
tvworks-server-parent Dependencies:
Only use successful builds from suitable ones
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
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?
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
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?
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.
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.
Yes, it should work this way.
If only B was changed and there were no changes in C, it should take existing C build.
Regards,
KIR
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
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
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.
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.
Hello Leon,
I agree that the current behaviour is confusing. Please watch the issue I created: http://youtrack.jetbrains.net/issue/TW-18052
Thanks!
KIR
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?
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