-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
2
-
1
-
Currently Bamboo only supports defining custom revision for default repo.
Workaround
First, you need to create and push branches with your desired revisions. Then create a custom plan branch:
Instead of passing “Branch name” click “Create plan branch manually”
This will allow you to create a branch plan without changing the default repository branch - we will keep it as master.
Enabling the branch plan can immediately trigger itself after creation, so we will start with it being disabled.
After clicking “Create” we need to do changes in the branch plan configuration. You should be automatically redirected to it, however, if not you can access it from the branch plan page
In the first tab of the branch plan config, you should see branches of all repositories used (at the bottom). Here we want to change the Jira Software Application branch.
Go to the “Repositories” tab.
Here you need to switch to the desired branch
Don’t forget to click “Save repository” at the bottom of the repository configuration
To verify if everything is correct go back to the “Branch details” tab and see what branches are configured.
For some plans, you may want to also disable automatic triggers of this branch plan. Here we will override it to run only when started manually. Toggle “Change trigger” and set “Trigger type” to “Manual”.
You should also enable the branch plan and click “Save”.
Configuration complete 
- links to
- relates to
-
WCAT-110 You do not have permission to view this issue
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[BAM-13213] Make it possible to define custom revision for multiple repositories
Unfortunately, we have to release our microservices with a CRQ and Ops team rejects deploying much CRQs, so we would like to collect all changes into one CRQ if it is feasible. But it is hard to collect manually, so I use a bamboo plan for that. But sometimes, we do not want to release the latest version.
+1
Our project has 3 repos
To build a release we git tag <release> across all of them
Unfortunately when trying to build a release by custom revision only the default repo is checked out correctly while the others aren't
It makes our build very cumbersome as instead of using normal "source code checkout" task we need to manually write script/command tasks for it
(we rather avoid changing our git workflow and start creating branches for each release just for this)
Kaja Mohideen
added a comment - Any idea of revealing which version can get this feature introduced. I'm the one who originally posted in AAC. We're working around this issue by using multiple plans and my application is doing all the handling to stitch the gaps. It's ugly but does the job 
This feature can help solve issues in building complex solutions.
Kaja Mohideen
added a comment - Any idea of revealing which version can get this feature introduced. I'm the one who originally posted in AAC. We're working around this issue by using multiple plans and my application is doing all the handling to stitch the gaps. It's ugly but does the job This feature can help solve issues in building complex solutions. Agreed Ted, this is weird logic. We've tried to make this easier by introducing bamboo.planRepository.<position>.revision where position is the position (1 to n) of the repositories defined against the plan. bamboo.repository.* and friends will eventually be deprecated.
Ted Sheibar
added a comment - The odd thing is that, when I have two repositories defined, referencing ${bamboo.repository.revision.number} takes the revision number from the source repository that was defined last in the plan configuration, NOT from the repository that was checked out during the build run.
Example:
One of our build plans is split into two stages: build and deploy. Git houses our code and SVN currently houses our configs (yuck, but a topic for another conversation).
The build stage clones from Git, builds, then calls an API to which we want to send the Git revision number. The deploy stage checks out from SVN, updates the configs, and commits back. Now, here's the problem...
At the end of the build stage, we're passing ${bamboo.repository.revision.number}. But, what gets sent is the SVN revision number even though the repo hasn't yet been checked out. Puzzling logic, indeed.
Ted Sheibar
added a comment - The odd thing is that, when I have two repositories defined, referencing ${bamboo.repository.revision.number} takes the revision number from the source repository that was defined last in the plan configuration, NOT from the repository that was checked out during the build run.
Example:
One of our build plans is split into two stages: build and deploy. Git houses our code and SVN currently houses our configs (yuck, but a topic for another conversation).
The build stage clones from Git, builds, then calls an API to which we want to send the Git revision number. The deploy stage checks out from SVN, updates the configs, and commits back. Now, here's the problem...
At the end of the build stage, we're passing ${bamboo.repository.revision.number}. But, what gets sent is the SVN revision number even though the repo hasn't yet been checked out . Puzzling logic, indeed. Ted Sheibar
added a comment - s/revision/release/g Ted Sheibar
added a comment - Yes, this would be very useful. Perhaps this can be integrated into the next revision?
Ted Sheibar
added a comment - Yes, this would be very useful. Perhaps this can be integrated into the next revision?
Our CI is arranged to released artifacts from multiple jobs in one build. These jobs build artifacts for different OS, СPUs, compilers, etc.
Bamboo agents run on different OS to make it happen. Needless to say that Perforce path is different for all of them.
For instance, Linux differs from Windows because of OS design.
Running `customized changelist number` seems to be natural solution to utilize if we need to fallback to some configuration.
As every job utilizes its own `perforce workspace`, it's strange that CL# applies only to the default one - the one on the top.
Could you please fix that?