Plan Branches and speculative merged code

[PeteSmith]

Hi all.

I've now got Bamboo building without Docker, it's all working fine. Having come originally from a place which had disparate build tools, it's nice to have an integrated solution where the CD/CD, issue tracking and repos all talk to each other.

I've got my basic build plan working, which builds the code (such as it is at this stage) when a merge is completed into the master branch.

I've also got Plan Branches configured too - when a PR is created, the plan branch is created, and when a commit is made into that branch, that branch code is built and tested.

What would make Plan Branches perfect is for it to behave more like MS Devops, which has a very similar function, but which is very slightly different.

If a PR is created, and the target branch is configured correctly, Devops will perform a speculative (temporary) merge of your feature branch code into the target, and build *that* code, rather than the pre-merge code.

This means that if your Plan Branch code passes, you know you're OK to finish the merge. The Bamboo way tells you that your branch code is OK, but not that the merged result of your work into the target branch is OK.

I've looked around, and I can't see anything obvious as to even if this is possible.

Can anyone confirm/deny what I'm doing is possible in Bamboo?

I appreciate that I could do this by manually merging the target branch into the feature branch, but it would be nice for the tool to do this for us.

Thanks.

Pete.

[Marcin Gardias]

Check the section "Automatic merge strategy" here: https://confluence.atlassian.com/bamboo/using-plan-branches-289276872.html

[PeteSmith]

Hi.

Thanks for getting back to me.

I'd seen that in the options, but it's not quite what I was after. This could even be a feature request!

What Devops will do is not just build the branch code, but will perform a local merge, but not persist it anywhere, and then build that code.

The danger of a "merge with successful build" is that the code which is being built isn't the result of the merge.

We're getting round it for now by constantly merging from our main branch into our feature branch.

Thanks anyway.

Pete.

[Marcin Gardias]

The danger of a "merge with successful build" is that the code which is being built isn't the result of the merge.

It is though. With automatic merging, Bamboo runs the merge first then builds. What is built is the merged code.

The only case when it wouldn't work 100% is if there are new commits on the target branch after the build has started. Not something Bamboo can prevent really.

[PeteSmith]

OK, this is interesting. So the code isn't finally merged until the PR is approved? I think "Branch Updater" may be exactly what we're after.

I'll take a look tomorrow.

Thanks!

[Bertil Ljungbeck]

Hi Pete,

Just wanted to check in with you, did this do what you were after.
I'm asking because I'm looking to gain basically the same as you describe. But Atlassians documentation still describes the functionality, as I read it, as a build of the isolated branch code and not the temporary merged code base.

I would have expected Atlassian to have updated their documentation by now, if it really did what you were after.

[bluemesa]

Hi.

It ends up that it does do what we need.

There's 2 ways of setting it up. When you auto-create your plan branch, it will use the speculative merge by default, i.e. it builds what would be built if the PR was approved. This is exactly what we were after.

There's another way of configuring the plan branch as well - if you create one yourself, you can specify what type of build happens.

We have release branches with hand-made plan branches in Bamboo. When you configure it, go to the "Branch Details" tab, and down at the bottom there's a section for Merging. For release branches, we don't select "Branch Merging Enabled". This means that it will only build the specified branch. We had a phase where the plan branch was created badly, and was building a speculative build against the release branch merged into Master, i.e. a master build not release. It meant we were potentially releasing Master, rather than the release branch.

Alternatively, if you want to create your own, select "Branch Merging Enabled", and select which branch you'd like to merge it with.

Once you're used to it, it's fine, but it's a bit of a steep learning curve, and the docs aren't 100% clear.

Hope this helps.