Snapshot dependency always using default branch

Hello.

I have the same issue as topic starter.
TC always take default branch from project A, even if i manually build project B with specified branch
(project B depends on project A)

What i need to check, why this is happening ?

Hello,

Could you please describe your case in more details?

Why do you need to select a specific branch as a parameter via a custom build when run QA build? Why do not you choose the branch in Changes tab Build branch selector?

@Marina, Selecting a Build Branch in the Changes tab from a custom build is what i mean by "select a specific branch via a custom build".

If i run the QA build with the 1.2.0 branch selected I expect this build to use the source code from the last Commit build for the 1.2.0 branch or if that does not exist then a new Commit build for the 1.2.0 branch would be triggered.  Instead a new Commit build is triggered and it always uses the develop branch.

It seems like the QA build is not passing the selected branch to the Commit build causing the Commit build to use its default branch which is develop.

Hello!

I am still a bit confused about your configuration. Please provide more details why you need to have the default branch and branch specification fields as parameters, i.e. %DefaultBranch% and %BranchSpecification% in your VCS configuration?

Marina,

We have the the default branch and branch specification fields as parameters because we want each build configuration to have a different default branch and monitor different branches but the builds have to share the same root VCS in order for snapshot dependencies to work.

For example the commit build's default branch is develop and the QA build's is a release branch.  The commit build branch specifications includes the develop, master, release branches and QA only includes release and hotfix.

This seemed to be the only way to achieve a setup where the build configurations share the same VCS root but can define their own default branch and specifications.

The idea for setting this up this way came from this blog post.

Hello,

Sorry for the delay.
I have not managed to reproduce your issue - it works exactly as expected for me. Could you please attach Build Chains page screenshot with at least one chain expanded?

Marina,

I recreated the snapshot dependency on one of the build configurations and and it is working now which was unexpected. We had tried that before and it did not work.  I double checked the VCS settings and they are still set with parameters like I described above.  Something else must have changed since December when I was first setting up these builds.

I have six more builds setup like this but have not had a chance to try adding the dependencies back for those yet.  Now I know that having parameters in the VCS for default branch and branch specifications does work.

And in case it helps someone else here is what that build chain looks like where the git branch is release/2.2.0:

Thanks

Hello,

I've the same type of problem.

First, with Teamcity 9, I have special build (for release branch) to follow gitflow like process. In build configuration, user can select if he is building a release or an hotfix, and then the major and minor version, build number and patch number for hotfix.

Those specifics builds have special validation, set build number based on "Branch name", check if no "develop nuget packages", etc....

the system use 2 variables to select the default branch and the Major.Minor version.

With this 2 informations, I build anoter configuration parameters

This new parameter is used to define default branch in VCS

I have also a special build to generate package, this build use a lot of dependencies. To select dependencies, I use Tag, which is a parameter (%TAG%) and dependencies is configured to use lastest build with specified tag.

This workflow was working very fine with Teamcite 9.

I've upgraded Team City to version 10 (actually version 10.4).

This workflow doesn't work anymore. Dependencies use only default branch (default value for parameter system.branche and system.MajorMinorVersion, 10 month old) with specified tag, even if a new branch and build with specified tag exist (10 minutes old). For the moment, I have to select manually branch for all 30 dependencies

Today, a developer want to make a new release of nuget. TeamCity ask to generate a new branch name ...

This new branch name doesn't match our process ("release/3.2" or "hotfix/3.1") and then build process fail.

Did I have to rewrite all process for my 140 projects, more than 400 build configuration (based on template) and about 250 VCS ?

Regards

I can confirm too that the behavior mentioned by OP occurs.

Here's a test case:

• Parent A has a snapshot dependency Child B
• A and B share the same VCS root
• The shared VCS root sets its default branch via parameter (e.g. %DefaultBranch%)
• A and B have different settings for %DefaultBranch%
• • Where A has %DefaultBranch% = "default_branch_a"
  • Where B has %DefaultBranch% = "default_branch_b"

When initiating a build of A on its default branch "default_branch_a", A will build "default_branch_a", however, B will be built on its own default branch "default_branch_b".

There is one mention of this behavior in another thread as well.  It mentions a few tickets, but those tickets specifically seem unrelated to this behavior.

Quote from Alina Mishina:
"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."

Although this behavior seems incorrect or at least quite counterintuitive, there does seem to be a simple workaround.  Assuming a configuration that is similar to the above test case:

• Within the build configuration of Parent A, you can override the %DefaultBranch% variable of all dependencies by setting `reverse.dep.*.DefaultBranch` equal to the parent's default branch.  So, in other words, add reverse.dep.*.DefaultBranch = default_branch_a, to Parent A's build configuration parameters.

Oh, what a surprise, run into another team city that isn't my fault but again a valid issue.
Is teamw city a product under active development or just a side project ?

Hi all,

as pointed out by Matthew, this was also discussed in another thread and is not actually a bug in itself, this is the design of how TeamCity expects to treat branches. A build triggered on the default branch will trigger its builds on default branches for their dependencies, even when they do not match default branch.

We have an issue in our tracker for the request to allow branch mapping here: https://youtrack.jetbrains.com/issue/TW-25586

Also, there is a relatively simple workaround. You can remove the ability to build on the default branch on the build that gets triggered, and add the branch to the branch specification instead. That way, TeamCity will never trigger a build in the default branch and thus the branch should be kept consistent throughout the chain.

@B Filipe, TeamCity is under active development, if you have any issues with it, please feel free to post them, we will try to help or address them.

I've spent a little while while trying to understand why my build always getting artifact from the default branch build. And I found interestring thing. If your branch does not have differences with the default one, your new branch looks at the same commit as the default branch. That's why TeamCity takes already built artifact from the default branch because it is the same. 

Adding new commit for my feature branch automatically tells teamcity that it has not a build for this commit and it starts building new dependency build.

Hi Denis Lapuente, we also stumbled into this.

It seems very odd that a snapshot dependency can run on different revisions given that enforcing revision synchronisations is such a vital use case for them.

> Also, there is a relatively simple workaround. You can remove the ability to build on the default branch on the build that gets triggered, and add the branch to the branch specification instead. That way, TeamCity will never trigger a build in the default branch and thus the branch should be kept consistent throughout the chain.

Useful workaround to know, but I'm curious to understand how this works in more recent versions of TeamCity, where disabling builds on default branch was replaced with branch filters.

Given a default branch of `refs/heads/main` for build A, I set the branch spec as:

```

-:<default>

+:refs/heads/*

```

But this still runs “main” as a default branch, and doesn't cause synchronisation across snapshot dependencies when build B depends on A.

I also tried using branch filters instead, but if I put `-:<default>` there and then `+:*`, the `-` has a higher priority, and now I cannot run in `main` at all (I still want to allow this if build B ran in `main`).

Can you explain how to apply your workaround now?