Bitbucket Server (maybe Cloud too): default reviewers support

[iamstarkov]

Intro

there is one thing which is missing in Bitbucket Server (Cloud too?): default reviewers.

You can configure them per team(project) or per repository. And then new PRs will have those default reviewers in place implicitly

From the Atlassian wiki:

Default reviewers allow you to automatically add one or more users as reviewers to pull requests. In addition, you can optionally specify how many of the specified default reviewers must approve a pull request prior to merging to ensure that a minimum level of review occurs.

You may have different roles in your team that should be automatically added to pull requests depending on the nature of the pull request. This can be achieved by assigning default reviewers for a specific repository, a specific branch, using a branch pattern, or with a branch type from the branching model. For example, you might specify a release manager be assigned to all pull requests targeting release branches.

Once assigned in the repository settings, default reviewers will be pre-filled during pull request creation. At that time the set of reviewers can then be adjusted for each pull request. — Add default reviewers to pull requests, Bitbucket support

---

What would you like Renovate to be able to do? I want renovate to take preconfigured default reviewers into account. Cli or config reviewers option doesn't work on scale and through out the time.

Describe the solution you'd like When renovate creates a PR, it checks the default reviewers for the branch it creates PR to, fetch default reviewers for it and assign those.

Describe alternatives you've considered

1. One options would be to use codeowners and paid plugin, but then you will have to maintain code owners in tens of repos if team changes.
2. Another options would be to use cli reviewers argument, but it doesnt work on scale for tens of teams with tens of repos each.
3. 3rd options would be to user repo's renovate config to configure reviewers, but that would prevent smooth on boarding and after on boarding will still have the same drawbacks as the 1st option: you would need to keep renovate configs in each repo in sync with up-to-date team staff.

Additional context Add any other context or screenshots about the feature request here.

• Feature description https://confluence.atlassian.com/bitbucketserver0515/add-default-reviewers-to-pull-requests-961275383.html
• Default reviewers API endpoint https://docs.atlassian.com/bitbucket-server/rest/6.1.3/bitbucket-default-reviewers-rest.html

[iamstarkov]

It is one feature we are missing at @nordnet. I filed it to request comments and feedback.

[rarkins]

If you configure default reviewers via Bitbucket's interface, doesn't Bitbucket itself add the reviewers once Renovate creates PRs? or maybe I misunderstand what you're hoping for

[iamstarkov]

I thought it would too, but apparently it doesnt. When you create PR via UI, then reviewers are being autosuggersted as in prefilled. I guess Bitbucket uses mentioned endpoint to retrieve the default reviewers and suggest the list before you create the PR manually

[iamstarkov]

I mean if you are open to have a custom logic in the BB server adapter, then I would hop on it when I will get time

[rarkins]

Please tell me if I understand the idea correctly: instead of configuring reviewers in both BitBucket ("default reviewers") as well as Renovate, we add the option that Renovate piggy backs on Bitbucket's configuration? i.e. use their API to learn the default reviewers and then add them to PRs without needing for those usernames to be configured in Renovate also?

[iamstarkov]

@rarkins correct

[rarkins]

Sounds like a good feature. Question is whether to make it opt-in, or opt-out, automatic or manual?

e.g. if no reviewers are configured, should we check with the Bitbucket automatically, or only if opted in?

[iamstarkov]

For us it was an expected behavior and I bet for whoever have their default reviewers configured it would be too. I say this feature should be enabled automatically with an option to opt out

[rarkins]

So:

• if reviewers are defined via config for the PR then use those
• else if default reviewers emails enabled then use them
• else of default reviewers disabled then add no reviewers

[iamstarkov]

sounds good

[viceice]

Maybe i can help to implement this 😄

[iamstarkov]

@ViceIce that would be nice

[viceice]

fetching the default reviewers is not a problem, but where to add them to the config?

@rarkins Do you have an idea, where this can be implemented?

[rarkins]

I’d add a new config option like “bbUseDefaultReviewers” of Boolean type set to true by default.

I think the only time we need to add these is when we create a PR so they should be “lazily” fetched only then.

So when creating the PR:

• are reviewers set in Renovate config? If so then no change in current behaviour
• is bbUseDefaultReviewers set to true? If so then query and cache them (for period of this run only) and use them

The bbUseDefaultReviewers option should be passed as part on createPR() somthat it’s configurable via packageRules if desired.

[viceice]

If it is a config option, it would be in the local bbs config. so we can check it in createPr.

I will look at it later :-)

[viceice]

github has a similar feature CODEOWNERS.

Should we support /prepare this too? so we only need one config option?

[rarkins]

I think GitHub apply code owners directly to PRs without opting in and without the ability to opt out. So BB seems different in this case - they do it optionally and not conveniently (eg there’s no Boolean option in create PR)

[rarkins]

“Local bbs config” means passed at initRepo? This would work but remove the ability to configure it per-PR

[viceice]

ok, so we have to pass the current config down to createPr

[rarkins]

Yes, an extra parameter to createPR, to be ignored by other platforms. Maybe can be inside an “options” object if we think it’s messy as a direct parameter, although does that make it harder later to TS the function definition?

[viceice]

an options object would be better. no problem for typescript, since we can make it optional.

[viceice]

maybe we should first refactor plattform to typescript before we make bigger changes?

I can do this in multiple small pr.

[rarkins]

I just wasn’t sure if “hiding” platform-specific config inside an “options” object was considered bad practice with Typescript. There’s no problem adding it as a first class function parameter right now

[rarkins]

Actually let’s just pass it in initRepo for now. ie it’s per-repo setting and not per-PR

[rarkins]

Then no change to createPr signature

[viceice]

as the docu states, we can get the default reviewer for a pr, but we have to fetch them in createPr, if bbUseDefaultReviewers is set. I'll try that :-)

[viceice]

should bbUseDefaultReviewers be an admin config? should it be true by default?

[rarkins]

@ViceIce making it an admin config means it's (a) only the bot owner who can decide it, and not the repo owner, and (b) most likely that you'll have the rule across the entire bitbucket server. I thought this might be desirable to configure per-repo instead?

[iamstarkov]

its not per-repo

[iamstarkov]

I mean, you can configure it for repos too, but usually each team has their own project on bitbucket server and then team configures list of default reviewers for the project, which reflects the team members and then each repository in the project inherits project's default reviewers. this way you can maintain default reviewers list for team's repos in one place

[viceice]

You can configure on repo too, if you like.

So if my pr is correct, you can disable within repo.

[iamstarkov]

yes, that's how I would do it too

[renovate-bot]

:tada: This issue has been resolved in version 17.2.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[ZyanKLee]

Hello dear gentlemen, I would like to see this great feature to be implemented for the Cloud version as well. Has there been a blocking issue that prohibited you from implementing it for BBC? Else I would ask my colleague to submit the necessary changes.

[viceice]

@ZyanKLee The cloud api is different, so i couldn't simply copy the changes. So feel free to submit a pr for that.