Data Center / Server π
Cloud βοΈ
To get started with Code Owners, watch demo video π and follow the instructions below:Β
CODEOWNERS
file into your repository as in the following example and Code Owners will add reviewers automatically to your pull requests: π & βοΈ# 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 |
The difference between the two merge check options in the Code Owners minimal approvals config is that
Min. # of approvals
@@@react_devs
because it only considers a global limit of merge approvals and ignores groups.@@@react_devs @john @marry @steve
If you need more flexible merge checks β see Merge Checks - only Data Center / Server π guide.
Note:
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: π & βοΈ