I'm going to talk to my manager about switching to Jenkins because of this.

Not sure this feature actually works on version 6.5.0.

I have 3 repositories linked to my build, they all use develop by default. Only plan branches are derived from the first listed repository

• repo1 - develop
• repo2 - develop
• repo3 - develop

My assumption is that a plan branch should be created from any of these 3 repositories, it appears only to create them from repo1 not repo2 or repo3. In Plan Configuration if i navigate to branch and use the Create plan branch i can only see branches that exist in repo1  and no option to even select another repository to do that manually.

This is evident by the fact it you change your ordering of repositories with automatic branching enabled it warns you to first change your branching configuration (set it to manulally)

What i would expect is that any repository listed would generate a new plan branch using that plan branch specifically for the build and defaulting to the default of any of the other branches unless there is an exact matching branch name in the other repository.

Perhaps this is what I'm looking for: https://jira.atlassian.com/browse/BAM-19898.

Is it possible to do this automatically?

Given a plan with two repositories, main and side, where each has two branches:

• /main
  • > master
  • feature/new-button
• /side
  • > master
  • feature/new-button

Bamboo creates a plan branch for feature/new-button and sets main to the repository branch to feature/new-button. However, side stays on branch master, regardless of whether the branch is the same name or not, like so:

• /main
  • master
  • > feature/new-button
• /side
  • > master
  • feature/new-button

I can go into the plan branch configuration and add feature/new-button manually, but is it possible for Bamboo to pick this up automatically? Or configure this externally, e.g. through the REST API? With the REST API I only see the option to query the available plans and add a new plan branch, but nothing about configuring them. I also tried supplying the suggested variable ${bamboo.buildBranch} as the branch name (both for Linked and non-linked repositories), but the build fails as it's unable to find the branch "${bamboo.buildBranch}" (quite obviously).

We have numerous connected plans each with different repositories and doing this manually is time-consuming and prone to error. I actually got the impression from most of these comments that doing it automatically was the desired behaviour.

Is it possible to do this? If not, is there a workaround? Or an open ticket for this?

@KyleSessions, Thanks! Didn't expect it to be released already.

@BrianFischer, it's now generally available as a download, go to https://www.atlassian.com/software/bamboo/download 

Wondering what happened to the 6.3 EAP. Went to download it to try it out and it isn't available at https://www.atlassian.com/software/bamboo/download-eap

Hi,

We just released an EAP for ver 6.3 which introduces support for multi repo branching. You can find the release notes and binaries here:

• https://confluence.atlassian.com/display/BAMBOO/Bamboo+6.3+EAP+Release+Notes 
• https://www.atlassian.com/software/bamboo/download-eap

Note that in this release, we only support manual configuration of branches.

If you check out this feature, please let us know your feedback. We are very interested in hearing how this works for you.

Thanks!

– Syed

Brian.Fischer166925441, watch out for the 6.3 EAP sometime next week.

@Syed Masood: Any news?

Update: This didn't make it to 6.2, but it's still in progress, and on top of the list in our backlog.

Would love to have this feature!

smasood@atlassian.com, can we get an update on this?

Thanks!

@Joel  Ok.

@brent - When you add your pointless comments to this thread, it messages everyone who's participated in this thread, if you could exercise good etiquette that'd be great. 

Bravo.

I met the manager of an antique product
Who said: A vast and commitless branch of git
stands in our repo... related to it in jira
outdated, a forgotton ticket lies, whose history
and passing comments, and sneer of disregard
Tell that its owner ill their products conceived
Which yet survive, documented on these lifeless things,
The product that mocked them and release that fed:

And on the ticket these words appear:
'My name is Unassigned, assignee of assignees:
Look upon my features, ye user, and despair!'
Nothing beside remains. Round the memes
of that colossal wreck, boundless and bare
The lone and level branches stretch far away.

Syed, thank you

We are waiting a new release, especially, AUG from Saint-Petersburg, Russia.

5 years, 2 months, 17 days in the making so far, this should be epic

Very likely this quarter.

That is excellent news! I've been waiting more than four years for this and have had to do all sorts of contortions, much as Brad reported. Any predictions of a time when we might expect to see it? This quarter? This year?

Thanks
Nick

briching1529827903

Hi Brad, Thanks for reaching out. I hear you.

I can confirm we are working on this. It's coming out soon-ish.

Syed,

We very much appreciate your continued updates.  Can you provide another update now?

I, like many others on this forum have put an awful lot of time into finding a work around that is ultimately doomed to fail in some regard.  I have literally tried everything that is mentioned in this thread, and also explored the possibly developing my own plugin checkout task to solve this.  But even that appears to be fraught with peril, since very likely the linked code commits will not be the correct ones as briefly mentioned link here.

Sadly, as of this writing, our flow will be limping along in the meantime with the following steps:

1. Create identically named branches in all relevant repositories in JIRA/Bitbucket
2. A short time later after bamboo has picked up the new branches and built them once (or more times), manually edit each branch plan and update a variable to the name of the actual branch plan.  This can be very tedious and error prone for those that have more than a handful of repos in their build.
3. Begin developing the feature on the branch, commit and push to see the progress of your branch as it builds in bamboo.

All of this still leaves out any notion of using built-in merging, which we would also greatly benefit from.

Please, please, PLEASE listen to your (enterprise) customers and implement this feature soon.

Kind regards,

Brad

Any clue on how to do this with linked repos using the bamboo specs library in Java?

gonchik.tsymzhitov2

Hi Gonchik,

This is a stretch goal for the next quarter. Not sure yet if we will be able to release it during this period, but fingers crossed.

– Syed

Hi Syed, 

Could you provide your internal priority for this issue? 

Because it is very needful feature. 

Thank you

Yes - it's been a long time requested - sad to see it deprioritized yet again. Between the lack of lack of traction on this and the retirement of the cloud version, I moved to CircleCI which simplified things greatly for me. 

Hi,

Thanks for all the comments and interest shown in this issue.

It is clearly a popular feature request, but we will most likely not be able to work on it during the next ~3 months. During this period, we have prioritized some other features (configuration as code, project level administration) that affect a much bigger set of users compared to this feature.

We might be able to work on this during the subsequent quarter, depending on how our capacity looks at that time. I will get back with another update around that time.

Regards,

– SG Masood

Bamboo Product Manager

That plan variables work in Linked Repository configuration is amazing (for hacks like this), horrifying (in that you can't reason about the repository on its own anymore, etc. though having branches as part of the linked repository config is its own issue and I think shouldn't be configured there) and annoying (given some of the places they don't work, like https://jira.atlassian.com/browse/BAM-12232 for example).

I had a ticket with Atlassian this is the solution they came up with. “The following workaround that might help you get around this limitation. Please note that by default Bamboo displays the revision numbers in the build result summary page based on the change detection process and since it does NOT take into account the current working branch for the other source repositories, it reports back with the revision number from their default branch, except for the main repository configuration.
We only managed to get this working with Git as the repository host (not Bitbucket Cloud, Bitbucket Server or Github) because we need to have the ability to set the branch name manually. The setup looks like this:

1. Create a Plan Variable named varBranchName.
2. Set the value of the variable to the name of the default branch from the main repository. In your case develop.
3. Create the Linked repository (Git type) and fill in the Branch name field with ${bamboo.varBranchName}.
4. Inside the plan branch configuration, on the Variables tab, override the varBranchName variable with name of the actual branch.
5. Trigger a new build on the branch.
6. Bamboo will automatically replace the variable ${bamboo.varBranchName} with the name of that branch and the build result summary will display the correct revision number for the branch.
With this configuration you don't need to use the script task to checkout the branch anymore, you can use the Source Code

Checkout task and point it to your repository configuration. As long as they are Git repositories, have the main branch name configuration set to ${bamboo.varBranchName} and have the variable manually overridden in the plan branch configuration, Bamboo will replace the variable value with the name of the branch. The downsides here are: you need to manually override the variable value at the plan branch configuration otherwise it won't work and we need to use Git repositories as opposed to Bitbucket Cloud, Bitbucket Server or Github repositories.”

I took it a little farther and gave each repo its own variable and then defined each of the branches default variable as a global variable of develop. Then I added a build plan task to use the API to submit the build and defined each of the variables in the submission process.

Example:
<added logic to define branch variables>
BranchPlans="&bamboo.varBranchPlan=$testbranch&bamboo.varProject1BranchPlan=$project1_branch&bamboo.varProject2BranchPlan=$project2_branch&bamboo.varProject3BranchPlan=$project3_branch&bamboo.varProject4BranchPlan=$project4_branch"
curl -X POST --user ${bamboo.BAMBOO_USERNAME}:${bamboo.BAMBOO_PASSWORD} "https://<bambooAPIurl>/rest/api/latest/queu/$BranchProjectBuildKey?executeAllStages=true$BranchPlans"

Hopefully this will work for some of you, it's not an ideal solution and really needs to be corrected by Atlassian to give us a much better way to report and run manual branches. But for now this seems to work.

For plugins, the API changes coming in 5.14 will make it significantly easier to make this functionality available.

Hello Guys,

At this point in time it is hard to share the plug-in but I will try to find a way to get it out there.

br

We are going to work on scripting this with git commands, but if @Jan Swaelens is willing to share this plugin (even paid), we'd be interested.

If we could open source it I would help with the up-keep/testing - we a number of plans that could really benefit from a good solution to this problem.

@Jan Swaelens - I second Joel's idea... Atlassian is never going to implement this change request.

@Jan Swaelens - Any chance you would open source, or share, this plugin?

We actually ended up having a plugin developed to handle these scenario's in a proper way ... I was done waiting.

You are better off pushing for this functionality in BitBucket Pipelines: https://bitbucket.org/site/master/issues?status=new&status=open&component=Pipelines

Four years is a short time according to Atlassian standard. The top requested feature started from May 2007, it is going to hit a ten year anniversary before it gets release. The iphone was not released when that bug was created.

Nevertheless, for a company that preaches on having good software practices and better release cycles, the lack of visibility is alarming. I am not sure whether the bigger customers have better insights into feature requests, but there is general void of public communication, and as such, I hold their software and their announce methodology to the same value as snake oil. You would not trust a fitness instructor if they were unfit and unhealthy, why should you trust a software process company when their processes are not working.

On the bright side, bamboo gets more love than some other products. There are pull requests for work that all Atlassian has to do is press the merge button, and that has not been done for years.

This has been open for four years and is the third most requested feature. Is this actively being worked on?

This would be extremely helpful to have implemented. Right now, we have to manually update the source repositories with the branch url when building a different branch.

+1

Another blocker. The more we try more stuff in Bamboo, the more we get disappointed because of blockers like this. We thought Bamboo is very flexible.

Plusing this issue.
My company case looks like that:
There is some plan template for dozens of modules, and it is used for testing and building docker images. So this plans for all modules differ from each other in only thing - repository.

Hi. This problem (Branch Plan using more than one repository) is a major issue for us. I can't see how we can use this product for our enterprise builds, since we have multiple repos that contribute to a build, and we are creating new branch plans often.
Please fix this
Thanks

The Bamboo team would do well to heed the sage advice of @sek and his handsome, dashing Bamboo guru, whomever that may be.

For those who do not want to script out the checkout of the secondary repository, it seems that the artifact publishing method given above is workable, as long as you have a usable 'default' case. This can (independently) track changes in multiple repositories.

Example Use Case:

Plan A (a library, or resource) provides necessary functionality to plan B.

• You want to monitor changes from both plans.
• Plan A may or may not consist of actionable code.

In Plan A setup:

• Add repository A. Set its branch to master, develop, or whatever you want the catch-all branch to be.
• Tasks:
  • Check out code
  • Do stuff to it (optional!)
  • Write a little text file inserting repo info (optional, but desirable for verification purposes)
  • Package it
  • Publish it as shared artifact A
• Now, optionally:
• Add branch support
• Add a dependency to Plan B (if you want to be 'tracking' changes from Plan A).

In Plan B setup:

• Add repository B. Set its branch to master, develop, or whatever you want the catch-all branch to be (though I would suggest making it the same as A, to avoid confusion).
• Tasks:
  • Check out code
  • Download shared artifact A
  • Unpack its contents into the desired location
  • Print the contents of your version file (optional)
  • Perform your other tasks

What happens is that you have the following situations for downloading:

• Any plan B branch (e.g. 'feature/name') will look for a branch of the same name in plan A, then grab that branch's artifact A.
  • release-1.2.3 in plan B will grab the last successful artifact from the release-1.2.3 branch of plan A.
  • NOTE: This should match the Bamboo branch name, not the SCM branch name--so either keep the Bamboo defaults or match your custom names.
• If plan B does not have a matching branch in plan A, then it will take the artifact from A's default plan (PROJ-A). It does not matter what the SCM branch is.
  • A plan B branch for release-1.2.3 which doesn't have a branch in plan A will use whatever your default configuration produces, such as 'master' or 'develop'.

You do (as noted above) miss having commits for both builds in the logs, but if the commits are sharing an issue, you can aggregate them through other means.

Another team at my company is using a similar strategy for dealing with branches in secondary repositories.

The main problem with doing that is that it means bamboo can no longer track what changes are actually in a build correctly. As the master (or whatever) branches may not change for any given series of branch builds. So the bamboo listing of relevant commits that make up a build is incorrect and I assume that means bamboo is no longer able to correctly associate jira issues with the builds that contain them anymore.

Those are both very useful features that get lost here.

I'm successfully using a variant of the 2nd option in my previous comment to checkout branches of a secondary repository.

• Instead of Source Code Checkout task, use a Script task with contents
  rm -rf project
  echo "checking out project branch: ${bamboo_SECOND_REPO_BRANCH_NAME}"
  git clone https://user:password@git-server/path/project.git --branch ${bamboo_SECOND_REPO_BRANCH_NAME} --depth 1
• In Plan Configuration->Variables, add a variable "SECOND_REPO_BRANCH_NAME" with a default value of "master"
  • note that this doesn't exactly match how the variable is referenced - that took a little bit to figure out
• Then when running the build, you can run->customized... and then override "SECOND_REPO_BRANCH_NAME" with a non-master branch. In practice, we see the automatic branch build fail, and then need to Run customized and put in the second repository branch name in order to get it to pass. So it's still a manual thing.

We are using git, so that's what the checkout command is for. Different SCM would need a different command. With git, the script could probably be extended to get the current first repo branch name and check if the second repository has that branch and if so use it. If I get around to implementing that, I'll post it here also.

We need this feature because we have no artifact repository and we're building everything we need everytime within the build And so when we're branching and building our new features we would like to change the other dependend repositories too. Thats our usecase.