Can I schedule bamboo to build all bitbucket mercurial feature branches?
Asked by Gareth Hughes:

Hi,

we are still perfecting our move to mercurial bitbucket from subversion.

(we are an ondemand customer)

We already have 50 feature branches and many fall seriously behind our default.

We have automerging turned on to push default into branches but because some branches lie dormant they get seriously behind and when you do get conflicts they turn into hell on earth.

Is there a way to schedule bamboo to build all the feature branches on our repo?

I know, we should never get conflicts but life's not like that when everyone is new to this game.

thanks for any advice


Answers:
author: PiotrA
body: Hello Gareth,

I think it is possible to work-around Bamboo by setting up a duplicate of the master/default repository and use multiple triggers for your plan. I'm not sure if that's possible on OnDemand (I believe yes), but I think it's worth a try. For a hint how to set that up, please visit my blog post: <http://blogs.atlassian.com/2013/09/tips-for-optimizing-bamboo-on-a-dvcs-team-pt-1/> - the relevant part starts with "Branch updater (Level = hard)" section. I hope this is what you are after, but in case I misunderstood you, feel free to leave a comment here. I'll monitor this question and respond if I can.

comments: author: Gareth Hughes
body: many thanks for the answer.

Let me just check my understanding of that article.

Our normal plan uses the Branch updater strategy.

In your duplicate plan you use the Gatekeeper rule instead and turn off Push On? Ok, get it, nice idea.

So how does a dormant branch get built? what triggers a build of that branch if there have been no commits? Can that be scheduled as an overnight task to go and build all of our feature branches?

(I admit to not having tried anything yet)


author: PiotrA
body: I'm speculating that if you would configure your plan to have a duplicate repository pointing to master/default, and if you would configure your plan to use two triggers: one "Repository Polling" that would be polling "Default" repository, second "Scheduled" that would be... scheduled, then you would have following situation:

- if you push something to the branch, it will trigger the branch build (due to "Repository Polling" trigger)  
- if you would push something to the master/default, it wouldn't trigger the branch build (because you would configure "Repository Polling" to not use master/default, right?)  
- on scheduled time the branch build would be build, no matter if there are any new changes (I think you could tweak that using different Trigger like "Repository Polling" instead of "Scheduled" - but that's up to you I reckon)

I'm not sure how would you like your branches to be updated - do you want Bamboo to automatically update your branches with master/default (and push that to your upstream repo)? If so, you would probably need to tweak a bit this scheme to use "Branch Updater" strategy with pushing enabled, but as I didn't do any practical research in that direction I'll leave this up to you. I'm not sure if it is 100% possible\&feasible though. Maybe not.

Does it make sense what am I describing?


author: Gareth Hughes
body: Yes, nearly!

I will postpone any further work on this until my Bamboo-guru colleague returns next week. Then I'd like to try this out.

many thanks


author: PiotrA
body: Okay.

When you happen to solve the problem in future, would you be so kind to post here the solution to satisfy my curiosity how it went? :)

regards


author: Gareth Hughes
body: One of the solutions to our problems was realising that we had a tabs/spaces culture clash for XML files.

We have a 50-50 split of Eclipse and Netbeans and hadn't spotted that Eclipse has separate XML editor settings for whitespace. Once we enforced spaces and dealt with the merge pain of reformatting all of our pom.xml down through 3 repositories and 50 branches things have settled nicely.

We now have far fewer merge conflicts and so we still haven't got round to trying your technique. Still, I intend to get to it soon.


Tags: cloud