Enforcing Code Owners in Bitbucket

[Tural Nasirov]

Hello,

I have added .bitbucket/CODEOWNERS file to my repo with following content:

file1.yaml reviewer1@example.com
/folder/file2.yaml reviewer2@example.com

When a user creates a pull request, the specified reviewers are automatically added. However, the user creating the PR can still remove the auto-assigned reviewers, add another reviewer, get approval, and then merge the PR.

We want to enforce that changes to the above files must be reviewed by the specific users listed in the CODEOWNERS file. For other files, any reviewer with access can approve and merge the changes.

Could you please advise how we can enforce these specific review requirements in Bitbucket?

Thanks in advance for your help!

[Ulrich Kuhnhardt _IzymesCo_]

Hello Tural,

I understand that you want to enforce a set of reviewers and their approvals as per your codeowners configuration.

Merge-checks are enforced with a Bitbucket Premium with $3(base) + $3(premium) per workspace user per month.

There are a few alternative apps on the Atlassian Marketplace for BB Cloud, that do exactly what you need.

One of them Workzone for BB Cloud (which we created for enterprise level BB Cloud users) enforces the reviewer set and also the approval quota.

If your developer Johnny removes reviewers from a PR to 'fast-track' the merge, Workzone will add reviewers back in automatically. Workzone also blocks the PR from being merged, if the required approvals from individual reviewers or groups are missing. And, the best news is that Workzone is available at $0.5 per user per month for workspaces > 5 users and free for small teams.

Cheers and happy coding

Ulrich

// Izymes

[John Keippel III]

I don’t think this quite answers the question? We’re on premium and the functionality is the same for us. CODEOWNERS automatically adds the necessary people, but they can be removed OR left there and once a default reviewer has approved, the branch can be merged. 

I feel like I’m missing something because otherwise this is sort of useless? I even have a meta rule which causes a person to be added as a reviewer, but again, once I got a single default reviewer to approve (our rule is one person that isn’t the author) the ability to merge becomes available. 

I thought this would augment the existing default reviewers and merge requirements by saying ‘oh, in addition to the default reviewers rules you ALSO need these people to review per CODEOWNERS’. 

But maybe not?

[Ulrich Kuhnhardt _IzymesCo_]

Hi @John Keippel III 

I think the core problem you and @Tural Nasirov are alluding to is that any native reviewer configuration, be it 'Default reviewers' or CODEOWNERS adds relevant reviewers at PR creation stage. If the PR is updated (for example a reviewer is removed manually) the same rules don't seem to be applied. Can you confirm?

[John Keippel III]

I guess? It’s just a straight up useless feature if there’s no actual enforcement. At PR creation all of the configured default reviewers are added and people are welcome to edit that, but merge restrictions are checked prior to allowing merge. CODEOWNERS should work the same way. If they chop off the DevOps team, despite CODEOWNERS matching on them changing some Terraform, for example, no merge. 

Again, otherwise I don’t know why this was even implemented in this way?

[Ulrich Kuhnhardt _IzymesCo_]

Hi John,

totally agree with you, CODEOWNERS only solves one side of the equation.

Let me know if you're open to try Workzone for premium enterprise reviewer and merge control as mentioned above.

Cheers Ulrich