1
votes

Seen multiple posts such as TeamCity show changes from snapshot dependencies, TeamCity show changes from snapshot dependencies, https://stackguides.com/questions/9366791/trigger-on-changes-in-snapshot-dependencies-does-not-seem-to-work-properly?rq=1,https://stackguides.com/questions/9982496/snapshot-dependency-dont-run-pending-changes-on-dependencies?rq=1

and none of them seem to address what i thought was a very simple requirement that i cant get my head around how to resolve.

I have the following build chain I want to setup in Teamcity

DS depends on Core DS depends on C5 AS depends on DS

PluginA depends on DS PluginA depends on AS

I have setup the snapshot dependency on DS for Core,C5 thinking that any change in Core/C5 should trigger DS to rebuild?

In the same vein PluginA should rebuild on a change to Core eventually due to the fact that its two dependencies should retrigger?

However this is not working as expected. The builds are shown as having pending changes but require manual rebuilds to actually work.

Do i need to configure finish build triggers for each snapshot dependency as well?

2

2 Answers

1
votes

If I'm understanding your description, the diagram below is the flow you have set up.

ChainDiagram

If this is correct, then you have two options, but before that, just a quick recap on Build Chains. A build chain is triggered in a "right-to-left" order, but then the actual builds are run in a "left-to-right" order. This means that if "Core" is triggered (scheduled or VCS trigger for example), then all builds that "Core" has snapshot dependencies on will also be triggered. But since it is the left-most node in the chain, nothing else gets triggered. on the other hand, if you had a trigger on "Plugin A", then ALL builds in the snapshot chain would be triggered, starting from left to right, so "Core" and "C5" would be triggered in parallel first, followed by "DS" and "AS" sequentially and then finally "Plugin A". So, your options are as follows:

  1. Add "Finished Build" triggers to the "DS", "AS", and "Plugin A" builds as appropriate for the exact behavior you are looking for.
  2. "Reverse" your trigger logic. It's not an exact "reversal", but you kind of have to think about it like that for it to make sense. Basically, you can have "DS", "AS", and/or "Plugin A" be the "trigger" build so to speak depending on the context. With the dependency chain setup properly, your builds will happen in the proper order. For example, if you setup a "VCS trigger" in "AS" which was pointing at the same VCS root as "Core" and/or "C5", then when a change is committed to either of those repos, "AS" will be triggered, which will in turn trigger all of it's dependencies, and each dependency will trigger its own dependencies as needed.

So you have to think about the exact behavior you want, and the context you want that behavior to happen and then setup your chain (and triggers) accordingly.

1
votes

Yes. For triggering forward (Core -> DS) you need finished build triggers. The snapshot dependency works backwards (you trigger DS, which triggers its deps, i.e. Core & C5).

It's quite common to set up both a snapshot dependency and a finished build trigger in parallel. Read more here.