nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Allow groups for default reviewers

plussier_hplmja

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

https://jira.atlassian.com/browse/BSERV-10660

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.

Accepted answers

All comments

Shiva_x9wuwp

Theodora Boudale

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:

https://support.atlassian.com/bitbucket-cloud/docs/set-up-and-use-code-owners/

This is the blog post announcing this feature:

https://bitbucket.org/blog/code-owners

Is this something that works for you?

Kind regards,
Theodora

plussier_hplmja

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

Theodora Boudale

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_hplmja

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

bitbucket

bitbucket-cloud