Explicit Default Branch Without VCS Root

Hello everyone,

I've got an interesting problem for you all. We have a a number of projects in a build chain, each producing their own artifacts. There are a lot of dependencies so to minimize disk space usage we don't output full "install" builds during CI. When we want to deploy a build, we'd like to be able to grab the latest build for a specific branch in a "package" build configuration that 1) collects all the artifacts and dependencies, 2) creates an RPM, 3) versions the package, and 4) dispatches it to a deployment management system. So far I've been able to get this working functionally, but the ergonomics are a bit off. Each package build requires the user to manually select the branch they want to build and the changes field includes all branches, which adds a lot of noise making it difficult to see what hasn't been packaged for deployment yet.

As an example consider the following build chain:

Project A <---- Project B <---- Project C <----- Package Build

With the following build project structure:

Continuous Integration -- builds all feature, release, and master branches using VCS triggers, runs unit and integration tests

Project A, Project B, Project C
Release -- Only creates a package for a specific release branch, assembling the relevant artifacts from the branch builds, fetching dependencies, etc

Sprint 20

Package Build -- Builds release/sprint20, applying version 2.5.* as defined in the "Build number format" property, uses artifacts from the existing CI build for that branch

Spring 21

Package Build -- Builds release/sprint21, applying version 2.6.* as defined in the "Build number format" property, uses artifacts from the existing CI build for that branch


This turns out to be tricky to accomplish because restricting the configuration to just a single branch looks impossible. The "package" configuration doesn't need a VCS root and should really just inherit branch information from the last build configuration in the build chain. However there is no good way to define the default branch, since if I run the build using the default branch it attempts to use the corresponding default branch for the CI builds (master) which is incorrect.

TL;DR: Can the default branch of a build configuration be defined without using a VCS root, and explicitly propagated to the dependend builds in the build chain (as opposed to being derferenced by each configuration in the chain)?

4 comments
Comment actions Permalink

Hi Sam,

You can configure artifact dependency as shown on the attached screenshot:
Screen Shot 2015-05-12 at 15.51.08.png
where %branch% is a prompt parameter. When you start the build you select needed branch, the build downloads the latest successful build's artifacts for this branch. Is this setup suitable for your case? If not, then please provide more details.

0
Comment actions Permalink

Hi Alina,

The setup you sugessted does work, but lacks a number of features we would like. For example, the ability to track changes that are included in a package build, and queue builds when there are changes deeper in the dependency chain. What we would really like is to be able to add the dependency of our package build as a "Snapshot Depenendency", this way it would be set up as part of the Build Chain. The problem we face  now with this set up is that if we specify a default branch as a variable in the VCS root, and then override that value in the build configuration we get the following scenario:


Project A Project B Project C Package Build (Sprint 27)
%default_branch% master master master release/2.6
The branch we would like to build from release/2.6 release/2.6 release/2.6 release/2.6
The branch that gets built master master master release/2.6


In other words, TeamCity propogates the "<default>" alias to subprojects when a build is triggered using the default branch. Then at each subproject, the "<default>" alias is resolved to that projects default branch. This is why, even though the default branch originally run from Package Build (Sprint 27) is "release/2.6", the subprojects end up building using "master". What I'm looking for is a way to keep the features of a build chain, but have the default branch in my package build resolved at the that level and then propagated explicitly in all subprojects.

0
Comment actions Permalink

Sam,

If a build configuration with branches has snapshot dependencies on other build configurations, when a build in a branch is triggered, the other builds in the chain also get the branch associated. However when the build is run on a default branch, its dependencies are also using the default branch, no matter to name those default branches use.

A workaround would be to configure Package Build with branches and trigger it on the "release/2.6" branch, not using default branch. These are related to a feature request TW-23395 and TW-25586.

0
Comment actions Permalink

Thanks Alina,

It looks like TW-23395 is more closely related to what we're looking for.

What we've done for the time being is configure the Package Build with a snapshot dependency and told everyone to use the following workflow. Click "Run..." > "Changes" > "release/2.6" to explicitly package 2.6 releases from the build chain. We've also let everyone know to set the change filters for the project to release/2.6 so changes from master or other release branches don't show up in the "Pending Changes" dropdown. This works quite well, though occasionally we do see someone make a mistake and run the default build. Since we haven't specified a VCS root on the Package Build this results in packaging master, which is not what want for a release build, but the labelling usually makes this obvious so they run another build with the correct change set. As I mentioned before, functionally this all works great, but the ergonomics are just a touch off. :)

0

Please sign in to leave a comment.