We have a very complex project with somewhere around 100 developers broken into teams. They each have an integration branch in each of many repos so their work can be merged together independently of other teams work. Unfortunately, for some repos, two teams have joint primary review ownership. The teams "know" what "their area" is, but it isn't a clear boundary in the code. So, we need to setup pull requests to have required and default reviewers something like this:
* Pull requests to integration/TeamA branch require approval from ArchitectA.
* Pull requests to integration/TeamB branch require approval from ArchitectB.
* Pull requests to integration/[Anything else] branch require approval from either ArchitectA or ArchitectB. Both architects are default reviewers in this case.
This way, ArchitectA is on TeamA's reviews for this repo, but ArchitectB is not. Unfortunately, I can't seem to set up this way because the rule is an "AND" as far as I can tell: If we add default reviewers for integration/* and also for integration/TeamA, then BOTH rules apply. (The documentation by Atlassian is very sorely lacking here and doesn't give any details.)
Does anybody have advice on how to do what I want, short of adding separate rules for all of our teams (12 teams which will change over time, 40 repos, so that is really not viable unless we script it)?
Hey Rob, unfortunately it's not possible to accomplish what you're looking for without changing your branch naming scheme or explicitly naming every branch under "integration". You can create a feature request at jira.atlassian.com, but I'm not sure this is likely to get implemented. We haven't had any similar requests. Would it be possible for you to change the naming scheme or tag branches to filter that way?
Hi Ben, thanks for the response. I think that we are going to have to just write code for this one. It appears that with Script Runner we will be able to add hooks for this. Given the size of organization and the level of customization we're doing to our whole infrastructure, that isn't an unreasonable solution.
As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...
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