2020 Roadmap: Per-branch configurations: when?

Answered

In the TeamCity 2020 Roadmap blog post (https://blog.jetbrains.com/teamcity/2020/03/teamcity-2020-roadmap-part-1-of-2/) it is mentioned that Per-branch configurations is in development. Two questions:

  1. When would this feature be released? I haven't found any more information on it nor can I find it in the issue tracker.
  2. My understanding with this feature is that builds on different branches in the same repository can have different build chains? This is huge for us. We cannot change our build chain because it means we cannot patch old versions (which exist on small branches from the past). We would love for different branches to have different build chains so our build chain can evolve with our product but then we can still build old versions with their old, unchanged build chains. At the very least allow us to add new build chain steps which would just get ignored in old branches.
4 comments
Comment actions Permalink
Official comment

Hi RK,

We had this feature assigned to 2020.2 and implemented it to an extent. After a review of this work we decided not to release it as it lacks some necessary elements to become a complete feature:

- it will not allow creating new build configurations in a non-default branch of versioned settings (or deleting them in the default branch, which is pretty much the same) and using them in a build chain in that non-default branch;

- if this functionality is turned on, a build chain configured by settings taken from a non-default branch is displayed as if some builds in it can be promoted along snapshot dependencies that are only present in the default branch. E.g. if you have a build chain A -> B -> C in the default branch (where C depends on B and B depends on A), and only A -> C in a non-default branch, a chain started in the default branch will still be displayed as if a build in A can be promoted to a build in B in that branch;

There was also no certainty of how stable this functionality is, as in some (although quite unrealistic) cases we observed it breaking build chains in non-default branches. 

So we decided to consider more substantial approach to the problem, i.e. to support proper multi-branch project model. But this discussion is still on the way.

As for your case, there are two ways around it:

1. You can just create a separate project for each branch of your versioned settings. Basically the versioned settings VCS root in each such project will be pointing to the same repository, but will have a specific default branch. This is how we do it building TeamCity project in fact. This solution will not only allow you to have different chains, but also different triggers etc.

2. You can try using the functionality that we developed, accepting its experimental status and the limitations mentioned above. To enable it please set a parameter `teamcity.internal.versionedSettings.modifyDependencies` in the respective project (in all branches of the settings, or in the parent of that project)  to `true`. You can also enable it for the whole TeamCity instance if you set an internal property of the same name to `true`.

Please let us know which path have your chosen and if this solution satisfies you for now.

Comment actions Permalink
  • it will not allow creating new build configurations in a non-default branch of versioned settings (or deleting them in the default branch, which is pretty much the same) and using them in a build chain in that non-default branch -> This is fine by us, we don't require this use-case.
  • if this functionality is turned on, a build chain configured by settings taken from a non-default branch is displayed as if some builds in it can be promoted along snapshot dependencies that are only present in the default branch. E.g. if you have a build chain A -> B -> C in the default branch (where C depends on B and B depends on A), and only A -> C in a non-default branch, a chain started in the default branch will still be displayed as if a build in A can be promoted to a build in B in that branch -> This is fine by us, we don't as of yet use build promotion.

As mentioned, the primary use-case here is simply making additions to the build chain in the default branch. In other words, we never delete build configurations, we only expand our chain with new steps. We just want non-default branches to succeed by ignoring any build configurations it isn't aware of that the default branch has defined. We would love to see this as a first-class feature in TeamCity.

We initially rejected option #1 (create new projects) because it means a lot of work on our end everytime we release software (which we use TeamCity to avoid much infrastructure work). It also eats into build configuration limits (though admittedly we aren't close to exhausting these yet). It also means developers have three different ways for building non-dev changes: either a non-default branch build in the main project, or go to a different project for legacy versions, or a non-default branch in a different project for legacy versions (as opposed to just always going to a non-default branch for any version).

We're not sure we'll be able to test the experiment feature in option #2 either.

0
Comment actions Permalink

The teamcity.internal.versionedSettings.modifyDependencies setting is exactly what we need.

What guarantee is there that this feature doesn't get removed or change behavior? Can this be made public and official so we can use it in our production instance?

0
Comment actions Permalink

The feature is currently experimental, which means precisely that there is no guarantee that it won't get removed or change behavior. This said, the fact that it is already shipped means that it is less likely to go through major changes. Adjustments are likely needed and until the dev team doesn't think it's ready it will be hidden behind that toggle and prone to change. It is a widely requested feature that will likely have a large impact in how teamcity is used so we need to be careful not to release it in an unfinished state. 

0

Please sign in to leave a comment.