• Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      The new branch functionality shows great promise. But, and there's always a but, it doesn't handle plans with multiple source repositories.

      For an example setup, I have code stored in the following svn locations:

      /svn/libraries/core/trunk
      /svn/libraries/widget-creator/trunk
      /svn/applications/magic-8-ball/trunk

      To create a clean build of the magic-8-ball application, I need to check out all three in order and build them. If I want to branch the magic-8-ball application for release and have it depend on specific versions of its libraries, the source directories might be:

      /svn/libraries/core/branches/3.14
      /svn/libraries/widget-creator/branches/12345
      /svn/applications/magic-8-ball/branches/1.2

      From a functional perspective, each of the source repositories in a plan needs to be able to have a separate source repository path when building a given branch. This path for the default build, this other path when building the '1.2' branch etc.

      On the UI side when configuring a Bamboo Branch, the current location for specifying a different source repository when building for a branch is partially non-intuitive. To my mind, especially if Bamboo's concept of Branch builds becomes more central to Bamboo's operation, having the different source repositories for Branches as additional options in the Configuration -> Source Repositories -> Edit Source Repository tab would make more sense. For Branch (pulldown) use [this] repository information with [x] same password or different password etc. I really like the idea of not having to retype the same repository password multiple times.

            [BAM-11544] Branching with multiple source repositories

            brian.fischer166925441 added a comment -

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

            brian.fischer166925441 added a comment - @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 

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

            brian.fischer166925441 added a comment -

            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

            brian.fischer166925441 added a comment - 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:

            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

            SG (Inactive) added a comment - 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.

            SG (Inactive) added a comment - Brian.Fischer166925441 , watch out for the 6.3 EAP sometime next week.

            brian.fischer166925441 added a comment -

            @Syed Masood: Any news?

            brian.fischer166925441 added a comment - @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.

            SG (Inactive) added a comment - 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!

            Daniel Lang added a comment - Would love to have this feature!

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

            Thanks!

            cirris_kyle added a comment - smasood@atlassian.com , can we get an update on this? Thanks!

            erickelly added a comment -

            @Joel  Ok.

            erickelly added a comment - @Joel  Ok.

            Joel added a comment -

            @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. 

            Joel added a comment - @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.

            Adrian Chan added a comment - 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.

            Brent Harrison added a comment - 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.

            Gonchik Tsymzhitov added a comment - 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

            Brent Cetinich added a comment - 5 years, 2 months, 17 days in the making so far, this should be epic

            Very likely this quarter.

            SG (Inactive) added a comment - 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

            nickstoughton added a comment - 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.

             

            SG (Inactive) added a comment - 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

            Brad Riching added a comment - 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: Create identically named branches in all relevant repositories in JIRA/Bitbucket 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. 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?

            Dylan Wilson added a comment - 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

             

            SG (Inactive) added a comment - 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

            Gonchik Tsymzhitov added a comment - 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. 

            Mike Holdsworth added a comment - 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

            SG (Inactive) added a comment - 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).

            Etan Reisner added a comment - 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.

            Jason Baron added a comment - 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.

            Przemek Bruski added a comment - 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

            Jan Swaelens added a comment - 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.

            Brad Riching added a comment - 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.

            Rich Duncan added a comment - 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.

            Thales Atlassian Admin Group added a comment - @Jan Swaelens - I second Joel's idea... Atlassian is never going to implement this change request.

            Joel added a comment -

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

            Joel added a comment - @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.

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

            Rob Jones added a comment -

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

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

            Henry Tam added a comment -

            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.

            Henry Tam added a comment - 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.

            Joel added a comment -

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

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

            Matt G added a comment -

            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.

            Matt G added a comment - 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.

            Rob Jones added a comment -

            +1

            Rob Jones added a comment - +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.

            Deleted Account (Inactive) added a comment - 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.

            Jason Jameson added a comment - 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

            David Clark added a comment - 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.

            Jerry Qassar added a comment - 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.

            Etan Reisner added a comment - 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.

            Stanley Kurdziel added a comment - 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.

            Felix Köhler added a comment - 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.

            Thanks for the feedback, part of the issue for us is that there's a fair bit of complexity in making branches selectable at checkout. We would have to refactor the way we handle repository which is a significant effort and therefore we have to be careful about the tradeoffs.

            We really see value in branching with multiple repositories, and it is our goal to solve that problem. However we do our best to mitigate development risks by not having too many complex projects at the same time. At the moment we're looking into https://jira.atlassian.com/browse/BAM-13600 which should require the attention of the team until the end of the year. When it ships we will be able to look at other complex projects to include in our backlog.

            Thanks,

            Sten

            Sten Pittet (Inactive) added a comment - Thanks for the feedback, part of the issue for us is that there's a fair bit of complexity in making branches selectable at checkout. We would have to refactor the way we handle repository which is a significant effort and therefore we have to be careful about the tradeoffs. We really see value in branching with multiple repositories, and it is our goal to solve that problem. However we do our best to mitigate development risks by not having too many complex projects at the same time. At the moment we're looking into https://jira.atlassian.com/browse/BAM-13600 which should require the attention of the team until the end of the year. When it ships we will be able to look at other complex projects to include in our backlog. Thanks, Sten

            I don't know how practical this is for others, but the workaround I am using is to create a plan for each repo. In plan A, you would designate shared artifacts from repo A for what you need in plan B. In plan B, you would add an "Artifact download" task that copies the files from plan A. Bamboo is smart enough to use a branch of the same name in this case.

            Kenny McClive added a comment - I don't know how practical this is for others, but the workaround I am using is to create a plan for each repo. In plan A, you would designate shared artifacts from repo A for what you need in plan B. In plan B, you would add an "Artifact download" task that copies the files from plan A. Bamboo is smart enough to use a branch of the same name in this case.

            Agreed Stan's first option would do handle all of our current builds. Can't believe they'd promote it's branching capability and that it's an enterprise solution. It's a great product and it can be called one or the other but it currently doesn't do branching of enterprise quality.

            Greg Geilfuss added a comment - Agreed Stan's first option would do handle all of our current builds. Can't believe they'd promote it's branching capability and that it's an enterprise solution. It's a great product and it can be called one or the other but it currently doesn't do branching of enterprise quality.

            Pity you can't vote for comments - Stan hits the nail squarely on the head for how this could work to get things going.

            Mike Holdsworth added a comment - Pity you can't vote for comments - Stan hits the nail squarely on the head for how this could work to get things going.

            I am using git as source control and have two repositories that are used for the Source Checkout task. Two possibilities (designed to be easier than the full request to implement) that solve what I need (and possibly even a fair percentage of the others requesting this feature?)

            Two low cost partial implementation options

            • Check for the same name branch in the 2nd repository and fall back to master. That way if repo1 is building with branch1 and if repo2 also has a branch1 branch, check it out instead of master. I'm happy enough to name the branches the same name.
            • Add a way to pass a branch name into the Source Checkout task as a branch variable. The branch could default to master when created as it currently does, but then in the branch configuration if there was a way to override the 2nd repository's branch (for only that branch configuration), that would also solve the problem. Could be a custom run variable.

            These both seem like pretty low cost options. The first wouldn't even need any UI (and how I came up with it was that the local bamboo guru guessed it might already be implemented that way)

            Stanley Kurdziel added a comment - I am using git as source control and have two repositories that are used for the Source Checkout task. Two possibilities (designed to be easier than the full request to implement) that solve what I need (and possibly even a fair percentage of the others requesting this feature?) Two low cost partial implementation options Check for the same name branch in the 2nd repository and fall back to master. That way if repo1 is building with branch1 and if repo2 also has a branch1 branch, check it out instead of master. I'm happy enough to name the branches the same name. Add a way to pass a branch name into the Source Checkout task as a branch variable. The branch could default to master when created as it currently does, but then in the branch configuration if there was a way to override the 2nd repository's branch (for only that branch configuration), that would also solve the problem. Could be a custom run variable. These both seem like pretty low cost options. The first wouldn't even need any UI (and how I came up with it was that the local bamboo guru guessed it might already be implemented that way)

            Have to agree with everyone else out there... this is really bad that a JIRA ticket cannot be used well when changes affect multiple repositories (e.g. source code, install script).

            It seems Atlassian likes eye candy features; but doesn't actually implement them for use in the real world.

            Craig Stevenson added a comment - Have to agree with everyone else out there... this is really bad that a JIRA ticket cannot be used well when changes affect multiple repositories (e.g. source code, install script). It seems Atlassian likes eye candy features; but doesn't actually implement them for use in the real world.

            Hi,

            I just wanted to provide an update on this request. At this stage it's unlikely that we'll address it before the end of the year.

            Thanks everyone for your feedback, please know that we read it and take it into account when prioritising our roadmap but due to other factors we are unable to put this development on top of the backlog.

            Thanks,

            Sten Pittet
            Bamboo Product Manager

            Sten Pittet (Inactive) added a comment - Hi, I just wanted to provide an update on this request. At this stage it's unlikely that we'll address it before the end of the year. Thanks everyone for your feedback, please know that we read it and take it into account when prioritising our roadmap but due to other factors we are unable to put this development on top of the backlog. Thanks, Sten Pittet Bamboo Product Manager

            I too have not found a suitable work around for this. It's definitely given me a black eye at work given I advocated for Bamboo based on it's branching integration with GIT.

            Greg Geilfuss added a comment - I too have not found a suitable work around for this. It's definitely given me a black eye at work given I advocated for Bamboo based on it's branching integration with GIT.

            Andrew: The repos variable is simply the result of finding all of the directories from the base directory. This is why I have assumption 2 above – that each repo is being checked out into a subdirectory of the base.

            Barry van Oudtshoorn added a comment - Andrew: The repos variable is simply the result of finding all of the directories from the base directory. This is why I have assumption 2 above – that each repo is being checked out into a subdirectory of the base.

            Can anyone explain how Barry assigns this repos variable?

            repos=`find -maxdepth 1 -type d -name "*" -printf "%f "`

            Is this a CLI query?

            I'm trying to get acess to a variable that has ALL repos within a plan. And ideally an indication of whether that repo has changed.

            Andrew MacKrell added a comment - Can anyone explain how Barry assigns this repos variable? repos=`find -maxdepth 1 -type d -name "*" -printf "%f "` Is this a CLI query? I'm trying to get acess to a variable that has ALL repos within a plan. And ideally an indication of whether that repo has changed.

            Facing the same issue as most people here, trying to manage branches with multi repositories plan is turning into a nightmare. I tried the proposed workaround of creating a plan variable and overriding it at branch level but when I set the branch field value to the variable it doesn't appear to be replaced and the checkout miserably fails with the following exception:

            com.atlassian.bamboo.repository.RepositoryException: java.lang.RuntimeException: com.atlassian.bamboo.repository.InvalidRepositoryException: Cannot determine head revision of '<user>@<git_server>:<projects_space>/<repository>.git' on branch '${bamboo.common.branch}'. Branch has probably been removed.
            

            It would be really helpful to have a reliable way to manage the branches of each repository in multi repository plans.

            Paul Thomas added a comment - Facing the same issue as most people here, trying to manage branches with multi repositories plan is turning into a nightmare. I tried the proposed workaround of creating a plan variable and overriding it at branch level but when I set the branch field value to the variable it doesn't appear to be replaced and the checkout miserably fails with the following exception: com.atlassian.bamboo.repository.RepositoryException: java.lang.RuntimeException: com.atlassian.bamboo.repository.InvalidRepositoryException: Cannot determine head revision of '<user>@<git_server>:<projects_space>/<repository>.git' on branch '${bamboo.common.branch}' . Branch has probably been removed. It would be really helpful to have a reliable way to manage the branches of each repository in multi repository plans.

            We are also facing the same issue and in need a quick resolution for JST-139881, workaround is good, but I will not be able to use it.
            Request to address this on high priority.

            Ankit Agrawal added a comment - We are also facing the same issue and in need a quick resolution for JST-139881, workaround is good, but I will not be able to use it. Request to address this on high priority.

            We're using the following shell script to work around this issue.

            #!/bin/bash
            
            repos=`find -maxdepth 1 -type d -name "*" -printf "%f "`
            
            for repo in ${repos}
            do
                if [ "$repo" != "." ]; then
                    if [ "$repo" != ${bamboo.mainRepository} ]; then
                        cd $repo
                        if [ $? = 0 ]; then
                            echo "$repo"
                            git checkout ${bamboo.planRepository.branch}
                            if [ $? != 0 ]; then
                                git checkout master
                            fi
                            git pull
                        fi
                        cd ..
                    fi
                fi
            done

            This makes a few assumptions:

            1. You're using git
            2. You're checking out each repo into a subdirectory of the main directory
            3. You have set up a "mainRepository" variable for the plan which is the name of the directory which should not run the very latest version

            The last item allows you to handle queued builds: so if you have commit abcdef and then push commit 123456, your first queued build will build abcdef.

            We have this set up as a script task immediately after checking out the repositories.

            Barry van Oudtshoorn added a comment - We're using the following shell script to work around this issue. #!/bin/bash repos=`find -maxdepth 1 -type d -name "*" -printf "%f " ` for repo in ${repos} do if [ "$repo" != "." ]; then if [ "$repo" != ${bamboo.mainRepository} ]; then cd $repo if [ $? = 0 ]; then echo "$repo" git checkout ${bamboo.planRepository.branch} if [ $? != 0 ]; then git checkout master fi git pull fi cd .. fi fi done This makes a few assumptions: You're using git You're checking out each repo into a subdirectory of the main directory You have set up a "mainRepository" variable for the plan which is the name of the directory which should not run the very latest version The last item allows you to handle queued builds: so if you have commit abcdef and then push commit 123456 , your first queued build will build abcdef . We have this set up as a script task immediately after checking out the repositories.

            samfulton added a comment -

            In that case, if a matching branch name exists then it uses that branch, otherwise it defaults to the parent plan's branch.

            samfulton added a comment - In that case, if a matching branch name exists then it uses that branch, otherwise it defaults to the parent plan's branch.

            jmo added a comment -

            We have a similar naming scheme as sam, but say if repo1 needs a hotfix but repo2 does not, then we've got branch: repo1/hotfix and branch: repo2/master that need to compile together, so having a single fixed branch name for every repo in the build plan doesn't really help there

            jmo added a comment - We have a similar naming scheme as sam, but say if repo1 needs a hotfix but repo2 does not, then we've got branch: repo1/hotfix and branch: repo2/master that need to compile together, so having a single fixed branch name for every repo in the build plan doesn't really help there

            samfulton added a comment -

            If the 'plan branch' switched the branch name for ALL the repositories in the plan, not just the default, then that would make way more sense. Especially when you have a 'development', 'staging', 'production' style branch naming convention across repos.

            We have 6 repositories with a 'master' branch, and 6.0, 6.1, 7.0 etc branches (standardized branch naming across each repository). So when we want to build the 7.0 branch, it should use that branch name for all the repos.

            samfulton added a comment - If the 'plan branch' switched the branch name for ALL the repositories in the plan, not just the default, then that would make way more sense. Especially when you have a 'development', 'staging', 'production' style branch naming convention across repos. We have 6 repositories with a 'master' branch, and 6.0, 6.1, 7.0 etc branches (standardized branch naming across each repository). So when we want to build the 7.0 branch, it should use that branch name for all the repos.

            quochuy added a comment -

            I need this feature too, I don't mind it to be manual selection but I'd like to have one build plan with multiple GIT sources and configure it to checkout a branch for all repos.

            As for now, I'm creating one build plan for each branch and not using the plan branch feature.

            Alternatively, I was thinking of using GIT submodules, create a dummy repository that would then use the other source repos as submodule in pre-created directory structure. Then the single build plan would checkout that dummy repo to checkout the other ones. But every time I update a source repos, I will need to also update the dummy one. Not sure if it will work though, just a thought

            quochuy added a comment - I need this feature too, I don't mind it to be manual selection but I'd like to have one build plan with multiple GIT sources and configure it to checkout a branch for all repos. As for now, I'm creating one build plan for each branch and not using the plan branch feature. Alternatively, I was thinking of using GIT submodules, create a dummy repository that would then use the other source repos as submodule in pre-created directory structure. Then the single build plan would checkout that dummy repo to checkout the other ones. But every time I update a source repos, I will need to also update the dummy one. Not sure if it will work though, just a thought

            Adam Lins added a comment -

            I had an active project that had multiple git repositories (about 12, all hosted on Fisheye). Each git repo specified in the plan's Source Repositories had ${bamboo.buildBranch} specified in the branch field. The main plan defined this to be 'master'. The branch plans overrode the variable with the branch of interest. It seemed to work OK for change detection, checkout, and build. For example, I can see that a commit that only appeared on a certain branch was correctly detected and triggered a build.

            I have never used mercurial, but if bamboo provides a similar field to specify the branch in the source repository specification then the plan variable method should work.

            Adam Lins added a comment - I had an active project that had multiple git repositories (about 12, all hosted on Fisheye). Each git repo specified in the plan's Source Repositories had ${bamboo.buildBranch} specified in the branch field. The main plan defined this to be 'master'. The branch plans overrode the variable with the branch of interest. It seemed to work OK for change detection, checkout, and build. For example, I can see that a commit that only appeared on a certain branch was correctly detected and triggered a build. I have never used mercurial, but if bamboo provides a similar field to specify the branch in the source repository specification then the plan variable method should work.

            jmo added a comment -

            Even getting a variable into the branch definition box, bamboo then doesn't substitute it during checkout leading to no builds and this error:

            Caused by: java.lang.RuntimeException: com.atlassian.bamboo.repository.InvalidRepositoryException: Cannot determine head revision of 'https://bitbucket.org/<account>/transportal.git' on branch '${bamboo.hack.branch}'. Branch has probably been removed.

            jmo added a comment - Even getting a variable into the branch definition box, bamboo then doesn't substitute it during checkout leading to no builds and this error: Caused by: java.lang.RuntimeException: com.atlassian.bamboo.repository.InvalidRepositoryException: Cannot determine head revision of 'https://bitbucket.org/<account>/transportal.git' on branch '${bamboo.hack.branch}'. Branch has probably been removed.

            jmo added a comment -

            Ugh, Bamboo automatically converts generic git repos with URLs @bitbucket.org into Bitbucket configured repos, so the variable I had defined as 'branch' is replaced by the dropdown with 'master' selected.

            jmo added a comment - Ugh, Bamboo automatically converts generic git repos with URLs @bitbucket.org into Bitbucket configured repos, so the variable I had defined as 'branch' is replaced by the dropdown with 'master' selected.

            In mercurial, both versions, the custom and the bitbucket both use a dropdown so it's not possible to put a variable name there.

            Perhaps that would be a simple stop-gap measure: make all dropdown menus include also a text field so that one can type an option not present in the listing.

            claudiofreire NA added a comment - In mercurial, both versions, the custom and the bitbucket both use a dropdown so it's not possible to put a variable name there. Perhaps that would be a simple stop-gap measure: make all dropdown menus include also a text field so that one can type an option not present in the listing.

            LZaruba added a comment -

            Hi,
            the puzzling part of the workaround is to use generic GIT repository although you might be using github or bitbucket. Generic GIT allows you to type in the variable into the branch field. Bamboo downloads list of branches which cannot be altered.
            This took me few hours to understand, hope I can save time to others

            Cheers

            LZ

            LZaruba added a comment - Hi, the puzzling part of the workaround is to use generic GIT repository although you might be using github or bitbucket. Generic GIT allows you to type in the variable into the branch field. Bamboo downloads list of branches which cannot be altered. This took me few hours to understand, hope I can save time to others Cheers LZ

            jmo added a comment -

            Would still be handy to have a step-by-step workaround using variables so people coming to Bamboo could get the app up and running now, vs waiting until the end of the year...

            jmo added a comment - Would still be handy to have a step-by-step workaround using variables so people coming to Bamboo could get the app up and running now, vs waiting until the end of the year...

            Lee Myring added a comment -

            Thanks Sten...that's great news that this is being looked into.
            Understood about not tying yourself to deadlines but it is great that you have shown us there is light at the end of the tunnel

            Lee Myring added a comment - Thanks Sten...that's great news that this is being looked into. Understood about not tying yourself to deadlines but it is great that you have shown us there is light at the end of the tunnel

            Hi,

            I'd like to provide a short update on this issue. We're aware of this issue but we cannot address it in the short term. We are currently working on some improvements to make it easier to configure and manage stages, jobs and tasks and we need to finish this before we address branching with multiple repositories.

            It is hard for me to provide a deadline for this issue. We're not going to address it in the next 6 months but there are chances that we improve branch management at the end of the year.

            Thanks,

            Sten Pittet
            Bamboo Product Manager

            Sten Pittet (Inactive) added a comment - Hi, I'd like to provide a short update on this issue. We're aware of this issue but we cannot address it in the short term. We are currently working on some improvements to make it easier to configure and manage stages, jobs and tasks and we need to finish this before we address branching with multiple repositories. It is hard for me to provide a deadline for this issue. We're not going to address it in the next 6 months but there are chances that we improve branch management at the end of the year. Thanks, Sten Pittet Bamboo Product Manager

            jmo added a comment -

            Maybe I'm missing something, but everywhere I can define/override a repo or branch they are dropdown select menus, I don't see any actual edit box where I could type in a variable as the branch name?

            should also mention Bitbucket does our repo management

            jmo added a comment - Maybe I'm missing something, but everywhere I can define/override a repo or branch they are dropdown select menus, I don't see any actual edit box where I could type in a variable as the branch name? should also mention Bitbucket does our repo management

            Right, I just looked at the git repositories form and you should be able to just specify your variable in the branch box. I used the Global variable for the convenience, it was trunk by default everywhere, but it should work with Plan Variables also.

            In the repository definition, did you specify your ${bamboo.planRepository.1.branch} variable in the branch box ?

            Sebastien Morin added a comment - Right, I just looked at the git repositories form and you should be able to just specify your variable in the branch box. I used the Global variable for the convenience, it was trunk by default everywhere, but it should work with Plan Variables also. In the repository definition, did you specify your ${bamboo.planRepository.1.branch} variable in the branch box ?

            Caley Goff added a comment -

            We also use git and stash for our repo management^

            Caley Goff added a comment - We also use git and stash for our repo management^

            Caley Goff added a comment -

            I would also like to add I've also found another solution to branching with more than one repo...
            Its a dirty hack but works.

            I have to set up a "gathering plan" for the repo I need resources from. It does nothing but checkout the code. Zip it up, and share an artifact. It does this for a set of defined branches I make available between the default repo of the plan, and the branching scheme I define under the branches tab. The branches HAVE to make the branching scheme of the main plan that needs to pull resources from other repos in other branches.

            So I then take my main testing plan or deployment plan, and pull in the needed artifacts for whatever branch I'm currently testing, and it pulls the artifacts for the most recent successful plan run that matches the main plans branch name

            I hope this also helps some

            Caley Goff added a comment - I would also like to add I've also found another solution to branching with more than one repo... Its a dirty hack but works. I have to set up a "gathering plan" for the repo I need resources from. It does nothing but checkout the code. Zip it up, and share an artifact. It does this for a set of defined branches I make available between the default repo of the plan, and the branching scheme I define under the branches tab. The branches HAVE to make the branching scheme of the main plan that needs to pull resources from other repos in other branches. So I then take my main testing plan or deployment plan, and pull in the needed artifacts for whatever branch I'm currently testing, and it pulls the artifacts for the most recent successful plan run that matches the main plans branch name I hope this also helps some

            jmo added a comment -

            Suppose I should also mention i'm using git, is why I chose those variable names.

            Thanks Sebastien, sounds like people here are say you can do it with just Plan Variables and override those with Branch Variables? Doesn't seem like a Global Variable should be required?

            jmo added a comment - Suppose I should also mention i'm using git, is why I chose those variable names. Thanks Sebastien, sounds like people here are say you can do it with just Plan Variables and override those with Branch Variables? Doesn't seem like a Global Variable should be required?

            The way I did it was create a global variable repoSource with a value of "trunk" and when I define my subversion repositories, I use the variable in the URL, something like:

            http://server/Path/To/Repository/${bamboo.repoSource}

            When I need to branch, I override the repoSource variable to "branches/MyBranch"

            Hope this helps...

            Sebastien Morin added a comment - The way I did it was create a global variable repoSource with a value of "trunk" and when I define my subversion repositories, I use the variable in the URL, something like: http://server/Path/To/Repository/$ {bamboo.repoSource} When I need to branch, I override the repoSource variable to "branches/MyBranch" Hope this helps...

            jmo added a comment -

            Even just a quick explanation of how to set a variable to override the branch being checked out by the Source Code Checkout task would be extremely helpful.

            I've defined two variables with key -> value:
            variable name: "bamboo.planRepository.1.branch" value "develop"
            variable name: "bamboo.planRepository.2.branch" value "develop"

            And a Source Code Checkout task that checks out two repos, but it will only checkout master on both. Obviously my variables either aren't being applied or are wrong. What am I missing?

            jmo added a comment - Even just a quick explanation of how to set a variable to override the branch being checked out by the Source Code Checkout task would be extremely helpful. I've defined two variables with key -> value: variable name: "bamboo.planRepository.1.branch" value "develop" variable name: "bamboo.planRepository.2.branch" value "develop" And a Source Code Checkout task that checks out two repos, but it will only checkout master on both. Obviously my variables either aren't being applied or are wrong. What am I missing?

            This is a critical use case for our organization. We need to be able to create identically-named feature branches in multiple repositories (BTW: it would be nice if we could do this in one operation from the originating JIRA issue). The plan branch should then automatically checkout this feature branch in each of our repositories in order to properly build the new feature.

            Brandon Barlow added a comment - This is a critical use case for our organization. We need to be able to create identically-named feature branches in multiple repositories (BTW: it would be nice if we could do this in one operation from the originating JIRA issue). The plan branch should then automatically checkout this feature branch in each of our repositories in order to properly build the new feature.

            Scott added a comment -

            There should be an option to choose which repositories are branched, for example if we have a plan which uses 5 repo's and only 3 of those repos require branches then there should be a option to select which repos are to be branched within the plan configuration.

            Scott added a comment - There should be an option to choose which repositories are branched, for example if we have a plan which uses 5 repo's and only 3 of those repos require branches then there should be a option to select which repos are to be branched within the plan configuration.

            Luying Pan added a comment -

            +1 Please support multiple repos.

            Luying Pan added a comment - +1 Please support multiple repos.

            Indeed +1, but lets be honest - using that concept fields ancient and is barely a workaround.

            Jan Swaelens added a comment - Indeed +1, but lets be honest - using that concept fields ancient and is barely a workaround.

            +1 for Barry's comment.

            Andrey Shovkoplyas added a comment - +1 for Barry's comment.

            Lee Myring added a comment -

            +1 for Barry's comment. Complete instructions would be a great help - I don't have time to "figure this out myself"
            I think the "me-too" comments at least show that there are a fair number of people out there wanting this change and the more noise we make the more likely Atlassian will fix this issue!

            Lee Myring added a comment - +1 for Barry's comment. Complete instructions would be a great help - I don't have time to "figure this out myself" I think the "me-too" comments at least show that there are a fair number of people out there wanting this change and the more noise we make the more likely Atlassian will fix this issue!

            I know that "me-too"s aren't particular helpful, but... Would it at least be feasible to put complete instructions as to how to achieve this using variables up on the documentation for Plan Branches in Confluence? That would at least help to mitigate the issue.

            Barry van Oudtshoorn added a comment - I know that "me-too"s aren't particular helpful, but... Would it at least be feasible to put complete instructions as to how to achieve this using variables up on the documentation for Plan Branches in Confluence? That would at least help to mitigate the issue.

            This is an issue that is seriously making me consider migrating to Jenkins.
            Plan branches seems like a good idea but there are many poorly thought out aspects of it e.g.

            • not having multi repositry
            • not triggering on anything other than default
            • because I use variables a lot, changing a repository branch in the UI is SOO painful. Click load repositories, branches is greyed out, change repository to new one, change it back to the first one, branches is no longer grayed out, select new branch....AWFUL
              This has to be fixed...please comment on this with whether it's going to be fixed soon, or not at all. It's coming very close to ditching Bamboo. Which is a real shame because its tight integration with ALL the features of JIRA is a real asset

            Lee Myring added a comment - This is an issue that is seriously making me consider migrating to Jenkins. Plan branches seems like a good idea but there are many poorly thought out aspects of it e.g. not having multi repositry not triggering on anything other than default because I use variables a lot, changing a repository branch in the UI is SOO painful. Click load repositories, branches is greyed out, change repository to new one, change it back to the first one, branches is no longer grayed out, select new branch....AWFUL This has to be fixed...please comment on this with whether it's going to be fixed soon, or not at all. It's coming very close to ditching Bamboo. Which is a real shame because its tight integration with ALL the features of JIRA is a real asset

            This is becoming a real show stopper for us too, not being able to direct multiple repository branches is blocking company wide adoption of bamboo. This is a real 'CI at Scale' requirement, please provide a solution!

            Jan Swaelens added a comment - This is becoming a real show stopper for us too, not being able to direct multiple repository branches is blocking company wide adoption of bamboo. This is a real 'CI at Scale' requirement, please provide a solution!

            We would love to have this as well.

            We have a project with a repository (a), and a second project (b) that is based on the first project, but has its own repository (and its own master, etc.)

            I would love to be able to set up branch merges where we could check out "develop" on repo b, merge "develop" on repo a into it, build, and do a gatekeeper commit if it passes.

            Benjamin Reed added a comment - We would love to have this as well. We have a project with a repository (a), and a second project (b) that is based on the first project, but has its own repository (and its own master, etc.) I would love to be able to set up branch merges where we could check out "develop" on repo b, merge "develop" on repo a into it, build, and do a gatekeeper commit if it passes.

            Joe Bowman added a comment -

            This feature is a blocker to us replacing our current build system with Bamboo. Our primary reason for moving to Bamboo would be to remove manual steps from our build process, so this definitely is a showstopper!

            Joe Bowman added a comment - This feature is a blocker to us replacing our current build system with Bamboo. Our primary reason for moving to Bamboo would be to remove manual steps from our build process, so this definitely is a showstopper!

            Same here, we have 3 repos that often have same-named branches in them. We can't combine the repos into one, so to make branch builds we have to set them up manually and this is a major pain.

            John Costello added a comment - Same here, we have 3 repos that often have same-named branches in them. We can't combine the repos into one, so to make branch builds we have to set them up manually and this is a major pain.

            This is preventing my team from purchasing a Bamboo license as this is definitely a required feature for our team. We're working across 6+ repos and cannot afford to add manual steps to our build process.

            Ryan Oksenhorn added a comment - This is preventing my team from purchasing a Bamboo license as this is definitely a required feature for our team. We're working across 6+ repos and cannot afford to add manual steps to our build process.

            Caley Goff added a comment -

            We love the auto-branch detection feature of Bamboo!!! This feature works great with plans that have a single repository. However for our shop we have some plans that require resources from different repositories in order to be stood up. Configuring multiple repositories for a plan is a breeze. However when I enable branch detection, our teams branches are not created as we expect.

            This applies to both git and stash, as we have used both, currently on stash. This is problematic, as at the very least our team expects "hotfix" and "release" branches to be created dynamically. Currently Bamboo polls "master" and "develop" for changes. If any of the branches are inactive for 5 days we delete them. We would love to have the feature branch be detected, but at this point with multiple repos for a plan none of the aforementioned auto branching works.

            I'm not sure if this has been suggested, but maybe offer the same list of checkboxes for repos that are configured for a plan... (the same list you have in the trigger tab), displayed on the auto branching tab. This way the user can select which repo the auto branching be set on. Bamboo should default to the repo settings configured in the linked or shared repos area.

            PLEASE ADD THIS FEATURE! Thank you!

            Caley Goff added a comment - We love the auto-branch detection feature of Bamboo!!! This feature works great with plans that have a single repository. However for our shop we have some plans that require resources from different repositories in order to be stood up. Configuring multiple repositories for a plan is a breeze. However when I enable branch detection, our teams branches are not created as we expect. This applies to both git and stash, as we have used both, currently on stash. This is problematic, as at the very least our team expects "hotfix" and "release" branches to be created dynamically. Currently Bamboo polls "master" and "develop" for changes. If any of the branches are inactive for 5 days we delete them. We would love to have the feature branch be detected, but at this point with multiple repos for a plan none of the aforementioned auto branching works. I'm not sure if this has been suggested, but maybe offer the same list of checkboxes for repos that are configured for a plan... (the same list you have in the trigger tab), displayed on the auto branching tab. This way the user can select which repo the auto branching be set on. Bamboo should default to the repo settings configured in the linked or shared repos area. PLEASE ADD THIS FEATURE! Thank you!

            This would be very helpful to our team. However, we're using Perforce, so we're not really concerned with the automated factors, we just simply need the ability for branches to override the defaults and allow multiple repositories. I've created build plans that sync (using NAnt & P4) in parallel with building, piece by piece, effectively eliminating Bamboo's up-front sync times, which can get to half an hour for some builds. This requires a tight view of the depot for the initial sync (essentially just build files), but in order to keep track of commits that apply to the plan I need a secondary repository set up with a wider view. I also need that wider view for triggers to properly work (otherwise it would only ever detect changes to the master build script). This works fine for any root plan, but since branches only get one (even when overriding the master repo), I cannot do this.

            Krist Smith added a comment - This would be very helpful to our team. However, we're using Perforce, so we're not really concerned with the automated factors, we just simply need the ability for branches to override the defaults and allow multiple repositories. I've created build plans that sync (using NAnt & P4) in parallel with building, piece by piece, effectively eliminating Bamboo's up-front sync times, which can get to half an hour for some builds. This requires a tight view of the depot for the initial sync (essentially just build files), but in order to keep track of commits that apply to the plan I need a secondary repository set up with a wider view. I also need that wider view for triggers to properly work (otherwise it would only ever detect changes to the master build script). This works fine for any root plan, but since branches only get one (even when overriding the master repo), I cannot do this.

            Adam Lins added a comment -

            I used Bamboo with a project that had 10+ repositories that made up the build. (I lost count

            We made plans that used a Bamboo variable to check out the same, specific branch from all of these sub-repositories. The branch plan was created manually, with a variable override to set the desired branch.

            The "missing feature" was being able to trigger a build from any commits on that branch in any of the repositories other than the primary repository. (IIRC, one repository is the primary repository, the one that Bamboo checks.)

            Adam Lins added a comment - I used Bamboo with a project that had 10+ repositories that made up the build. (I lost count We made plans that used a Bamboo variable to check out the same, specific branch from all of these sub-repositories. The branch plan was created manually, with a variable override to set the desired branch. The "missing feature" was being able to trigger a build from any commits on that branch in any of the repositories other than the primary repository. (IIRC, one repository is the primary repository, the one that Bamboo checks.)

            Rob Kooper added a comment -

            We have this with our git repository as well. We have a project that has 6 repositories that make up the build for the project. Bamboo is setup to automatically create branch builds based on the source repository.

            Right now it will only checkout the branch for the first repository, but will use the master for all others. For us the best would be to check out the same branch on all repositories (if it exists, otherwise the master) and build it.

            Rob Kooper added a comment - We have this with our git repository as well. We have a project that has 6 repositories that make up the build for the project. Bamboo is setup to automatically create branch builds based on the source repository. Right now it will only checkout the branch for the first repository, but will use the master for all others. For us the best would be to check out the same branch on all repositories (if it exists, otherwise the master) and build it.

            Craig Otis added a comment -

            It would be great to see this implemented. We have two source repositories - a "products", and a "utility". They each have a shared naming scheme for their branches: `patch`, `minor`, and `master`. (Think of `master` as a `major` release branch for long-term development.) When we try to set up branch plans however, we can only have the "products" or the "utility" repository properly adhere to the automatic Bamboo branch checkout. So assuming `products` is the default source repository, our branch plans can not get `patch` of "products" and `patch` of "utility". It can get `patch` of one, and `master` of the other.

            I know there is an SCM branch variable that can be used to write a script that checks the repository out manually, but it would be great if each source repository had an option to adhere to the current plan branch strategy.

            Craig Otis added a comment - It would be great to see this implemented. We have two source repositories - a "products", and a "utility". They each have a shared naming scheme for their branches: `patch`, `minor`, and `master`. (Think of `master` as a `major` release branch for long-term development.) When we try to set up branch plans however, we can only have the "products" or the "utility" repository properly adhere to the automatic Bamboo branch checkout. So assuming `products` is the default source repository, our branch plans can not get `patch` of "products" and `patch` of "utility". It can get `patch` of one, and `master` of the other. I know there is an SCM branch variable that can be used to write a script that checks the repository out manually, but it would be great if each source repository had an option to adhere to the current plan branch strategy.

            Travis Dimmig added a comment - 31/May/12 8:42 AM
            Without this feature, the new "branching" capability of Bamboo is useless for projects that checkout from multiple repositories. Each of my repositories has a branch for dev of a specific feature, but I can only override one of them to point to the branched code.

            +1

            Jeroen van Dun added a comment - Travis Dimmig added a comment - 31/May/12 8:42 AM Without this feature, the new "branching" capability of Bamboo is useless for projects that checkout from multiple repositories. Each of my repositories has a branch for dev of a specific feature, but I can only override one of them to point to the branched code. +1

            FYI, there is now a bamboo.branchName variable for each plan branch so you do not have to create your own branch name variable as a work around.

            James

            James Dumay added a comment - FYI, there is now a bamboo.branchName variable for each plan branch so you do not have to create your own branch name variable as a work around. James

            Travis and Bruce, I've emailed you offline with details on how to access the build that has the Automatic Branch detection for Subversion and the release notes.

            James Dumay added a comment - Travis and Bruce, I've emailed you offline with details on how to access the build that has the Automatic Branch detection for Subversion and the release notes.

            Hi Travis,
            Ill be in contact with both Bruce and yourself once we have something working for you to try!

            Cheers,
            James

            James Dumay added a comment - Hi Travis, Ill be in contact with both Bruce and yourself once we have something working for you to try! Cheers, James

            I would be interested in trying a beta of automatic branch detection for Subversion when you have one available.

            Travis Dimmig added a comment - I would be interested in trying a beta of automatic branch detection for Subversion when you have one available.

              mparfianowicz Marek Parfianowicz
              38fcfa868271 Bruce Campbell
              Votes:
              372 Vote for this issue
              Watchers:
              217 Start watching this issue

                Created:
                Updated:
                Resolved: