2

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 beta/* 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. I also take different post-build actions in the different configurations, for example the release configuration carries out deployment actions.

As an example of what I call 'non determinism', I have just merged a feature branch via a pull request into develop. I get a build in my Integration build configuration, which builds the develop branch. But then I also get builds on my other two build configurations, even though nothing in their branch specifications has changed; this is definitely not what I want because my release configuration, for example, deploys things. Here's a screen shot with the offending builds highlighted: enter image description here

Update - Additional Information Here is the overview of an 'offending build' enter image description here And here is the trigger configuration enter image description here

I'm clearly not understanding something about how TeamCity is supposed to work with Git. I am under the impression that build configurations are only supposed to build things that fall under their Branch Specification. Where are the other two coming from? Why do these builds get triggered when the branch specification doesn't include develop (or refs/heads/develop)? Is there a way I can stop this from happening?

I've tried raising this on the JetBrains support forum but I don't seem to be getting any traction there, so I thought I'd reach out to the StackOverflow community.

Tim Long
  • 13,508
  • 19
  • 79
  • 147

1 Answers1

1

If you have a build trigger that triggers any time there are changes, you will get this behaviour. I have a very similar setup in my project and I normally specify all branch specifications in the trigger build section.

Biswajit_86
  • 3,661
  • 2
  • 22
  • 36
  • Thanks for responding - have posted additional details requested. If I'm understanding you correctly, are you suggesting that I need to specify the branches _again_ in the trigger? If so, then what's the Branch Specification for? – Tim Long May 05 '15 at 19:50
  • branch specifications work fine for overriding the naming conventions (like the changes you did in parenthesis for picking shorter names for branches). When it comes to branch specifications, there are some gotchas and I do have my own doubts for what exactly is picked up or filtered in the branch specification tab (for ex the default branch , develop is always picked up). The trigger specifications however work exactly down to a dot and are better suited to selecting/filtering specific branches. Feel free to reply if I am unclear – Biswajit_86 May 05 '15 at 20:30
  • I see what you mean... My build configurations all inherit from a common template and I try to minimise the differences between the configurations, I was hoping the branch specification would be enough. I guess not! Well, a small price to pay I suppose if the build works properly. I experimented with it a bit and my trigger filter doesn't seem to be working properly. I wonder if you would be able to provide an example of a trigger filter vs. a branch specification from one of your builds? (Anonymized if necessary, of course). – Tim Long May 06 '15 at 17:43
  • I tried for ages to wrestle TC into submission but whatever I tried it conspired to defeat me at every turn. For example, if you want to set the branch filters on the VC trigger, you can't do that as part of the template! In the end I gave up on branch filters in the trigger and went back to just using branch specifications, which I set as a configuration parameter in each of my build configurations. I got around the fact that 'develop' (i.e. the _default branch_) would trigger everywhere by creating a dummy branch called NoBuild and making _that_ the default branch. Nasty hack, but it works. – Tim Long May 07 '15 at 16:57