For a while now, I've been cracking my head on how to implement gitflow with maven into Bamboo, while not giving up Bamboo's great features like plan branches and deployment projects.
I'll sketch our environment first, before going to ask questions.
Because the jgitflow-release-plugin seems to be messed up and does things weirdly, we've written our own release plugin for maven. It basically has 3 goals:
This plugin works great, if you run it manually on your pc. But if I want to configure it on Bamboo, I seem to fail the configuration.
Here are a few of our requests:
We have tried using the default maven-release-plugin on a manual stage, and execute it only on the 'master' branch, but this updates the version to SNAPSHOT (which we don't want on the 'master' branch), and we are unable to use the -RC versions in the 'release/xxx' branches.
Ideally what we've been thinking, is that there should be the ability to 'override' branch configuration. So that one type of branch does Stage A, Stage B and Stage C, while other branches execute Stage A, Stage C and Stage D. Also, the ability to add 2 manual (only manual) stages which are executed in a XOR pattern. So first Stage A, then Stage B1 XOR Stage B2 and then back to Stage C.
So for the question, is there a way to configure our requests in Bamboo, without having to configure 3 different project plans and over complicating things?
We've implemented something similar. Although we're using Gradle, I'm very familiar with Maven. So:
Thanks, so in short, what you mean is we have 2 Plans. One that automatically creates plan branches for 'develop', 'bugfix/xxx', 'feature/xxx' and 'hotfix/xxx'. This plan branch has 1 stage, with 1 job that does a maven clean install.
The other plan auto creates plan branches for 'release/xxx' branches and has a deployment project associated. Does this plan branch do a maven clean install or does it also do the deploy? Does it get triggered by each commit? Because a release candidate version is associated with a release within maven, so doing 2 deploys (to the repository) will fail. The actual bump-version, does it get executed in the deployment project? The actual release (so the merge to master and tagging), where does that get executed?
Anyhow, even with these questions, it is a start to fix our problem
Incident response is a team sport, and customer support is an integral part of any team. While Ops is working hard to solve the problem at hand, support is on the front lines communicating with custo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs