Allow groups for default reviewers

plussier
Contributor
July 31, 2024

This request is copy of a request from Bitbucket Data Center here:

We have certain groups in our organization that have the responsibility to review and approve pull requests in certain high-impact repositories. When people join/leave the group, we have to go into each repository and add/remove that user. Ugh. 

I'd like to be able to specify a group when setting up default reviewers for a repository.

Currently I can specify groups every where else, but not in the Default Reviewers configuration, which makes it very difficult to maintain when people leave/join different teams or groups.  This functionality is standard and best practice in almost every groupware application used by most organizations.

2 answers

1 vote
Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 5, 2024

Hi,

We released the CODEOWNERS feature a few months ago, which allows you to automatically add reviewers in pull requests based on the .bitbucket/CODEOWNERS file. You can specify workspace groups in that file; the documentation for this feature is here:

This is the blog post announcing this feature:

Is this something that works for you?

Kind regards,
Theodora

plussier
Contributor
August 6, 2024

Hi Theordora,

 

Thank you so much for this information. I can definitely see where this will be useful within our organization. However, we still have a need for use of groups with Default Reviewers.  The use case is to define groups of people who must approve a PR for merging to protected branches.  While the CODEOWNERS feature is useful, because it is contained within the repository itself, it means anyone can change the contents.

 

We require essentially "admin" level protection for these groups. For example:

- our Release Engineering team must approve merges to protected branches

- Changes to ITAR restricted code bases must be approved by U.S. based engineers.

- Security changes/reviews must be approved by our Security team

Most of the groups operate across many repositories but are not "code owners". Therefore, it is desirable for these types of groups to be defined in a central location and applied to repositories by those with Bitbucket Admin privileges rather than in a file which can be changed by anyone with repository access.

 

Thanks.

--

Paul

Like Kristian likes this
Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 6, 2024

Hi Paul,

Thank you for the feedback.

I would like to note two things:

  • Both default reviewers and CODEOWNERS reviewers are not enforced. A user raising a PR can always remove reviewers from the create pull request page. It won't be possible of course to merge the PR if you are enforcing merge checks with a certain number of approvals and that number has not been reached, but reviewers can always be removed from that list.

  • The CODEOWNERS configuration is always read from the destination branch of a pull request. If the destination branch is protected via branch restrictions and the user can't write directly to the destination branch, it won't make a difference if the CODEOWNERS file is changed in the source branch. Such a change can of course be seen in the PR diff and the user can be asked to remove the change so it doesn't get merged in the destination branch.

Does your use case concern users that have write access to the destination branches?

Kind regards,
Theodora

plussier
Contributor
August 6, 2024

Hi Theodora,

 

Thanks for pointing out that CODEOWNERS is enforced based on the destination branch, that's actually very helpful and could well solve the issue.

 

We do use branch restrictions to enforce a minimum number of Default Reviewers currently, but it seems that CODEOWNERS and teams.yaml might be a more flexible way to do this and we'd merely restrict write access via branch restrictions instead.

 

I'm not going to commit to saying "we don't need groups for default reviewers" quite yet, but I'll certainly give this a serious shot and see if we can't do just that :) 

 

Thanks again!

--

Paul

Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 7, 2024

Hi Paul,

Thank you again for the feedback!

I also wanted to add that you can reference workspace user groups in the CODEOWNERS file.

If you want to avoid the complexity of defining groups in the teams.yaml file, and then manually editing this file when people leave or join the team, you can use only the CODEOWNERS file and reference your workspace's user groups there. Then, you would only need to add or remove users from the workspace's user group when there are changes in your team.

Please also note that you would need to use the merge check Minimum number of approvals (instead of default reviewers approval), as users added to the CODEOWNERS file are not considered default reviewers.

Please feel free to let me know how it goes when you've had the chance to try it. If you think there's a use case not covered by CODEOWNERS, I'm happy to discuss further to see if we can find a solution or create a feature request.

Kind regards,
Theodora

E Glenn Denison
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
August 29, 2024

Hi @Theodora Boudale ,

Could you help confirm for me the one of the capabilities of CODEOWNERS?

The use case:
Imagine that I have a Bitbucket Project which has many diverse Repositories under it, and I am required by policy or regulation to enforce a standard for review on all members of that Project.

For example, I may require that at least N member(s) of a Release Managers group approve any PR to a Release branch, or else it cannot be merged. I'm fine if the person raises the PR and removes some or all-but-N of the members of that group, so long as they are blocked if they haven't gotten N approvals.

The question:
Is CODEOWNERS able to configure a policy like that at the Project level, to be enforced on all Repositories under that project?

Default Reviewers goes half way, but without the ability to use named Reviewer Groups in the Default Reviewers feature, we would have to assign the appropriate people to Default Reviewers one-by-one, by name.

Syahrul
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
September 1, 2024

Hey @E Glenn Denison 

Based on my understanding, I believe what you are looking for is likely Branch restriction. Using this, you can have specific numbers of users for PR approval before the branch can be merged or any other settings for PR merge.

Regards,
Syahrul

0 votes
Shiva
Banned
August 1, 2024

Currently I can specify groups every where else, but not in the Default Reviewers configuration, which makes it very difficult to maintain when people leave/join different teams or groups.  This functionality is standard and best practice in almost every groupware application used by most organizations.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events