VCS triggering seems a bit non-deterministic for Git branches

I use a GitFlow branching strategy. I like to have 3 build configurations per project:

  • Integration - builds from develop, feature/* and hotfix/* with branch specification
    • +:refs/heads/(develop)
      +:refs/heads/feature/(*)
      +:refs/heads/develop/(*)
      +:res/heads/(hotfix/*)
  • Beta - builds from release/* with branch specification
    • +:refs/heads/(release/*)
  • Release - builds from master with branch specification
    • +:refs/heads/(master)


Note the use of brackets to set my preferred branch names. The reason I have these 3 builds is because I use the build configuration name as part of the build name, so for example I get builds in the format 1.2.3-Integration.27, the final number '27' is a project-wide shared build counter.

As an example of what I call 'non determinism', I have just merged a hotfix. In GitFlow, hotfixes get merged into master and develop. Since I added the hotfix branch to the branch specification after I pushed the branch, I did not get a build for that. Fair enough. So then I merge the hotix and I get the following builds, in this order: and with these branch names

  1. /refs/heads/master
  2. master
  3. /refs/heads/master
  4. develop


Huh? I would have expected two builds, on branches named "master" and "develop", per my branch specifications. Where are the other two coming from?

--Tim

3 comments
Comment actions Permalink

Hi Tim,

Sorry for the delay replying to your post.

Let's collect all the details to figure out if this is a bug or "as designed" behavior.

Could you please add the default branch settings you use for all threee build configurations?
Please also note builds in what build configurationa and what branches you get after you merge the hotfix.

If you have more than one VCS root in any of the build configurations, please also note that.

0
Comment actions Permalink

I'm a little bit pressed for time this week, I will follow up with you early next week.

Alternatively, this is a public repository and I have enabled 'versioned settings' so the TeamCity configuration is right there in the repo. You could clone the repository and reproduce my build from the settings. https://bitbucket.org/tigra-astronomy/horizon-data-interchange

Regards,
Tim

0
Comment actions Permalink

I've had many distraction slately but I would like to pick up this thread again, if that's OK... Because I am banging my head against a wall trying to figure out TC's non-deterministic building behaviour.

Basically the problem is: I commit to my 'develop' branch and TeamCity builds that, but it basically builds it 3 times, on build configurations that don't have 'develop' in the build configuration.

My build strategy is based around GitFlow, which means I have two long-running branches called 'master' and 'develop'. Short lived branches generally brach off from develop into feature/*, hotfix/* etc.

I maintain 3 build configurations, called 'integration', 'beta' and 'release', all based on a common template called 'gitflow'. The 'gitflow' template sets the branch specification as a variable %BranchSpecification% and that is overridden in each of the build configurations, as follows:

integration:
     +:refs/heads/(develop)
     +refs/heads/develop/(*)
     +:refs/heads/feature/(*)
     +:refs/heads/hotfix/(*)
     +:refs/heads/bugfix/(*)
     +:refs/pull-requests/(*/merge)
beta:
     +:refs/heads/(release/*)
     +:refs/heads/(beta/*)
release:
     +:refs/heads/(master)

These configurations all share a common VCS root, which has 'develop' set as the default branch.

I would be happy to send you a full configuration report by privately but there are details I don't want to share publicly.

The behaviour I want is that the beta and master configurations should only build when there is a push to the bracnhes in their branch specification.
What I actually get at the moment is that both of those configurations (seemingly randomly) pick up pushes on 'refs/heads/develop' (that is the exact branch name they use).

I'm willing to accept this might be a problem with my configuration if you can explain to me how I can achieve my aims.
Best regards,
Tim Long

0

Please sign in to leave a comment.