Data Center / Server 🗄
Cloud ☁️
To get started with Code Owners, watch demo video 🗄 and follow the instructions below:
View file | ||||
---|---|---|---|---|
|
1. Put a CODEOWNERS
file into your repository as in the following example and Code Owners will add reviewers automatically to your pull requests: 🗄 & ☁️
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
# Either put this in a file called CODEOWNERS or .bitbucket/CODEOWNERS
# Lines starting with # are comments.
# Configuration lines start with CODEOWNERS.
# To restrict code owners functionality for a certain destination branch,
# you can add the CODEOWNERS.destination_branch_pattern followed by a branch pattern
# to your CODEOWNERS file. This file is then only active for pull requests with matching destination branch.
# For example if you want code owners to be active only for the branch master, add
CODEOWNERS.destination_branch_pattern master
# And if you also want to protect release branches, just add another line with a pattern like
CODEOWNERS.destination_branch_pattern release/*
# For supported pattern format, please check https://confluence.atlassian.com/bitbucketserver070/branch-permission-patterns-996644139.html .
# Enables subdirectories overrides, where a CODEOWNERS file in a subdirectory overrides all settings
# Ideal when you have independent projects in subdirectories which require independent rules
# By default this is disabled and only the CODEOWNERS at the top of the repository is used
# CODEOWNERS.toplevel.subdirectory_overrides enable
# Suppress info comment on pull request creation about added code owners. Info comment will be added by default.
# CODEOWNERS.toplevel.create_pull_request_comment disable
# Every rule line is a file pattern that is followed by one or more code owners.
# This user will be the default owner for everything in the repo.
* @PeterTheHacker
# Ordering is important! The last matching file pattern has the highest precedence.
# So if only a Java file is in the pull request, PeterTheJavaExpert is the code owner
# and not the default owner PeterTheHacker.
*.java @PeterTheJavaExpert
# You can also use Bitbucket groups which start with '@@' compared to single users.
# This will add all members of the Bitbucket group JSExperts.
*.js @PaulTheJSGuru @@JSExperts
# If you want, you can define your own code owner groups instead of using Bitbucket groups.
# This will define a new group MyDevs, both including users and other groups:
@@@MyDevs @PeterTheHacker @PeterTheJavaExpert ann@scala.lang @@JSDevs
# For Bitbucket users and groups with spaces in their name, put them into double quotes.
*.ts @"Paul the JSGuru" @@"Dev Ops Team"
# You can also specify code owners by email address if you prefer:
docs/* docs@example.com
# When your glob expression contains spaces, put the glob into double quotes.
"a/path with spaces/*" docs@example.com
# AnnTheScalaPro is the code owner of all files in the /src/main/scala directory at
# the root and all its descendants (e.g., /src/main/scala/com/x/y/z.scala).
/src/main/scala/ @AnnTheScalaPro
# ci/* will match all files in the directory ci, but not deeper in
# the directory hierarchy (so ci/jobs/prod.yml will not match).
ci/* @devops
# You can use '!' for negation in front of file pattern without any code owners afterwards,
# to unset all previously defined code owners of the files.
# e.g. devops group wants to review everything under ci (as defined above),
# except ci/playgrounds.yml, which nobody needs to review:
!ci/playgrounds.yml
# It's also possible to use double-asterisk globs. Here's an example that will match
# all JS files under /src/components.
src/components/**/*.js @@MyDevs
# GroovyMaster owns any files in the groovy directory anywhere in the
# file tree (e.g., src/main/groovy/com/x/y/z.groovy).
groovy/ @GroovyMaster
# Files starting with a `#` or a `!` can still be used by escaping them.
\#myfile.rb @PeterTheHacker
\!yourfile.rb @PaulTheJSGuru
# It is important to protect CODEOWNERS file as well because otherwise it can get deleted
# or moved within a pull request; so we want to assign a code owner to it which can prevent this
CODEOWNERS @CTO |
2. To enforce approval of a pull request by Code Owners before merging, enable the "Code Owners minimum approvals" Merge checks: 🗄
The difference between the two merge check options in the Code Owners minimal approvals config is that
Min. # of approvals
- of all code owners: this is the best strategy when you don’t use code owner groups like
@@@react_devs
because it only considers a global limit of merge approvals and ignores groups. - for each group: if you use code owner groups, you might want to use this merge check strategy.
- It allows you to configure a threshold of approvals based on your code owners groups, e.g. if you configure "2" in this merge check and you have a group
@@@react_devs @john @marry @steve
- then only 2 of the 3 of this group need to approve a PR to merge it (that applies for every group that is assigned to the PR).
If you need more flexible merge checks → see Merge Checks - only Data Center / Server 🗄 guide.
Note:
- Ensure to have a Code Owners rule covering the CODEOWNERS file itself, to prevent unwanted changes regarding enforced approvals.
- Protect branches for which you want enforced approvals with Branch permissions, e.g. Prevent changes without a pull request.
- Repository administrators can overrule the enforcement, by disabling the merge checks for repository administrators.
- e.g helpful during unplanned absences
3. Create a pull request and the app will add all matching code owners as pull request reviewers: 🗄 & ☁️
If you have enabled the merge checks, the pull request cannot be merged until the required code owners have approved the pull request: 🗄
If you change your pull request, the app will recognize this and adds additional pull request reviewers, if needed according to updated PR content: 🗄 & ☁️
Child pages (Children Display) |
---|