Setting pull request default reviewers for a complex project

[Rob Lefebvre]

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)?

[Ben Stuart]

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? 

[Rob Lefebvre]

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.