how do I create a push-based build chain? (as opposed to the default pull-based one)
Say my team is developing a bunch of packages. A `deploy` build task is triggered on these various projects whenever there's a git commit in `master` with a tag that starts with `v-` (release, version). This is set up and works just fine.
Some package X depends on some Ys.
Using build chains and dependencies, I can make it so that when I want to build an X, all the Ys with some changes since their last build will be re-deployed.
How do I make it so that whenever a build for a Y is triggered, any X depending on it will also get rebuilt?
Ideally it shouldn't cause a rebuild on any of the other Ys, as the Ys we want are already deployed because of their own triggers, but there might be additional non-release commits that would count as changes and would make them rebuild anyway. The only way I know to avoid this is by creating something like a `releases` branch, and getting triggers on those, so that every change is bound to be a release.
Please sign in to leave a comment.
Hi,
if the Ys have their own triggers, you can set a Finish Build Trigger on X that will trigger X whenever that Y is finished. This said, because of the snapshot dependencies, it will still pull Ys, and if they have pending changes they will get queued up for a rebuild.
Do you actually need to have snapshot dependencies on them? You might want to consider artifact dependencies without snapshot if you don't, as those will allow you to simply pick up whatever Ys are producing from their last successful build. Another option could be to have a separate X that does this, instead of reusing the same, which could have the finish build triggers I mentioned instead. By having an X that has snapshot dependencies, and a second X that only has artifact dependencies, you would have one that will trigger the rebuilds, and another one that would just use the artifacts without triggering.
Otherwise, if you have snapshot dependencies with pending changes, TeamCity will always build them, so you will need to set up separate build chains for separate rebuild conditions.
"Finish Build Trigger" while removing all snapshot dependencies seems to be exactly what I need!
In my case, what each "deploy" build does is push to an apt server, and the other builds are docker images that pull from that apt server and push new versions of their own debian packages, so it's all side effects. Using the artifacts would make development outside of the CI considerably harder.
In this scenario, I guess no dependencies of any kind need to be defined, and we can use "finish build trigger"s instead. Thanks!
Hi,
sorry I didn't link to it the last time, it should have been there from the start. If you are using the finish build trigger, we have a special note about using finish build triggers without snapshot dependencies, where we recommend not to do it without considering the drawbacks: https://www.jetbrains.com/help/teamcity/configuring-finish-build-trigger.html
oh, didn't notice that. Is the only drawback that TC doesn't promote dependencies unless you're using a Schedule Trigger?
Hi,
I'm not exactly sure what you mean, so, to try and be clear, I'll expand a bit on triggers:
-Triggers only decide when to trigger and what single build to trigger. This includes schedule triggers.
-Snapshot dependencies work in their own way. When one build with snapshot dependencies is triggered (independently of how), their dependencies will be brought up for building/reuse. Exception here would be retry build trigger which does only retry itself.
Neither schedule triggers, finish build, vcs or any other triggers will promote dependencies if they don't exist as snapshot. This is why I brought up keeping X as snapshot and as artifacts separate if needed. Without knowing your usecase, it was hard initially to make appropriate suggestions.
For the most part, the core limitation is branching. From the 3 limitations listed, one limits which branch can be applied, while the other 2 apply to situations in which commits arrive at the VCS Roots between the first build starting and the build being triggered by the finish build. While this is a real issue that in many places applies, it might not apply in many other situations, so you would need to consider it.
Since TeamCity 2019.1, there is a way to use a different set of revisions from the same branch instead of enforcing the same revision to all builds (which is what you want, have a new revision being built using older revisions of other ones). We have just introduced this functionality, as a toggle in the snapshot dependency configuration. For most builds, it will behave as usual, but if you have a build of a new revision of something that you want to trigger your "Y" with, you can promote it, and this toggle will allow you to select different dependencies (a.k.a. they won't need to build). This only applies for manually triggered builds, though, as you need to select which revisions will be used.
Hope this helps.