-
Suggestion
-
Resolution: Done
-
Linux, Subversion
-
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.
- duplicates
-
BAM-13995 Plan branch should be able to override multiple source repositories
- Closed
- followed by
-
BAM-19898 Plans braches using multiple repositories could automatically checkout them using the same source branch name
- Gathering Interest
- incorporates
-
BAM-18527 Do not run Change Detection after customized run
-
- Closed
-
- is duplicated by
-
BAM-14875 Be able to assign branches on multiple repositories
-
- Closed
-
-
BAM-15062 Automatic branching from multiple repos
- Closed
-
BAM-12880 Being able to clone multiple separate repositories to the same branch in the same job
- Closed
-
BAM-13995 Plan branch should be able to override multiple source repositories
- Closed
-
BAM-15963 Specify secondary repository at build plan branch level instead of build plan level
- Closed
- is related to
-
BAM-11660 Autogenerated Branch-specific variables
- Closed
- relates to
-
BAM-11662 Default repository should expose its branch name as a variable
- Closed
-
BAM-11803 Provide flexibility in choosing a repository while branching a plan
- Closed
-
BAM-19854 Create plan branches for all repositories defined in a plan
- Gathering Interest
- was cloned as
-
BAM-19873 Rest API Method for branching with multiple source repositories
- Closed
- links to
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
[BAM-11544] Branching with multiple source repositories
@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.
Update: This didn't make it to 6.2, but it's still in progress, and on top of the list in our backlog.
@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.
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
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
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:
- 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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
In that case, if a matching branch name exists then it uses that branch, otherwise it defaults to the parent plan's branch.
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
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.
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
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.
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.
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.
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
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...
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
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 ?
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
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...
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.
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.
Indeed +1, but lets be honest - using that concept fields ancient and is barely a workaround.
+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.
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!
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.
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.
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.
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.
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.)
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.
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
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.
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.
@KyleSessions, Thanks! Didn't expect it to be released already.