コード所有者の設定と使用
コード所有者について
コード所有者では、.bitbucket/CODEOWNERS ファイルをリポジトリに追加し、.gitignore のような構文を使用してコード パスを個人やチームにマップすることで、リポジトリ内のコードを担当する個人またはチームを定義できます。ご提供いただいた情報は、変更内容に基づいて、Bitbucket のプル リクエストに最も適したレビュアーを自動的に割り当てるために使用されます。
CODEOWNERS ファイルを設定する
CODEOWNERS ファイルを、リポジトリのルートにある .bitbucket というディレクトリに作成します。そのファイルをリポジトリにコミットすると、「CODEOWNERS」ファイルがあるブランチを対象として新しく作成されたプル リクエストは、指定されたロジックに基づいて候補レビュアーを自動的に追加します。
To start, you can populate the CODEOWNERS file with the full example of the CODEOWNERS file we’ve provided below, or continue reading for specification details and create your own from scratch.
CODEOWNERS の概要
コメント
コメントは # で始まり、行の先頭に置くことも、任意のテキストとインラインにすることもできます。ただし、読みやすくするために、インライン コメントは通常、行の末尾に置きます。
# Im a comment!パスのマッピング
ファイル内の各行は、1 つまたは複数のユーザー参照が続くパス パターンである必要があります。パターンは .gitignore 構文とほとんど同じルールに従いますが、次の例外があります (CODEOWNERS ファイルでは機能しません)。
# で始まるパターンを \ を使ってエスケープして、コメントではなくパターンとして扱う
! を使用してパターンを否定する
[] を使用して文字範囲を定義する
改行区切り文字が新しい所有権ルールとして解析されるため、ユーザー参照はすべて同じ行にある必要があります。1 つのパターンに対する複数のユーザー参照はスペースで区切る必要があります。
# Each line is a file pattern followed by one or more owners.
# Pattern matching rules are approximately the same as .gitignore syntax
* individual@example.com individual2@example.com ユーザー参照
ユーザーは、メール アドレス、ユーザー名、グループ名、またはチーム名のいずれかで参照できます (これについては後で詳しく説明します)。メール アドレスは通常のメール アドレスと同じ形式で、ユーザー名の先頭には @ 記号を 1 つ付け、グループの前にはそれを含むワークスペースのスラッグの後にスラッシュとグループの名前を付ける必要があります。
foo.py individual@example.com # Plain email addresses
bar.py @individual-username # Prefix usernames with `@`
baz.py @workspace-slug/group-slug # Prefix group slug with the workspace slug優先順位
順序は極めて重要です。CODEOWNERS ファイルの最後の一致パターンが最も優先されます。次の例では、JavaScript ファイルのみを変更するプル リクエストを誰かが開いた場合、@js-owner のみ (グローバル所有者ではない) がレビューをリクエストされます。
JavaScript を変更してプル リクエストを開き、マークダウン ファイルも開いた場合、両方のルールが一致し、全員がレビュアーとして追加されます。
* global-owner1@example.com # Owns all files except *.js
*.js js-owner@example.com # Owns only *.js files選択戦略
解析された所有権ルールによって、あるグループがチェンジセット所有者であることがわかると、追加のロジックを使用してそのユーザー グループから個々の所有者を選択します。明確な戦略が選択されていない場合は、グループから 1 人のユーザーがランダムに選ばれます。
利用可能な戦略は all、random、least_busy です。最初の 2 つでは、すべてのコントリビューター、またはランダムな「N」人のレビュアーが追加されます。ここで、「N」は random(2)/least_busy(3) のように渡されるオプションの数です。least_busy 戦略では、ユーザーがすでにレビューしているオープン プル リクエストの数でユーザーをソートし、設定されたコントリビューターの数を選択します。
least_busy と random の各戦略では、オプションの括弧と数値引数を省略することは、(1) を明示的に設定することと暗黙的に同じです。
* @workspace-slug/everyone # equivalent to `@workspace-slug/everyone:random(1)`
*.js @workspace-slug/frontenders:all
*.py @workspace-slug/backenders:least_busy(3)
*.sql @workspace-slug/dba:random(1)チームをコード所有者として追加する
グループやメンバーの管理は通常、ワークスペースのリポジトリ コラボレーターやコントリビューターにとっては範囲外です。Group 参照を柔軟に利用しながら、ワークスペースで昇格された特権が不要になるように、.bitbucket ディレクトリの CODEOWNERS ファイルの隣に teams.yaml という名前のファイルを定義できます。
このファイルには、CODEOWNERS ファイルと同じ config-as-code パラダイムを使用して管理されるレビュアー グループのアドホック定義が含まれています。
teams.yaml の構文例
frontend: # Name of the team
contributors: # Array of contributors by email address
- individual@example.com
- individual1@example.com
- individual2@example.com
- individual3@example.com
- individual4@example.com
- individual5@example.com
reviews: # Configuration for selecting PR reviewers
strategy: least_busy # Reverse sort by # of open PR's they are reviewing
select: 2 # and select the top 2 contributors
backend:
contributors:
- individual@example.com
- individual1@example.com
reviews:
strategy: random # Randomly sort all users
select: 1 # and select the top 1
seniors:
contributors:
- individual4@example.com
- individual5@example.com
reviews:
strategy: all # Select all users, no filtering/sorting applied
# No `select` argument required; ignored if specified使用可能な選択戦略はさきほど定義したグループ戦略と同じですが、代わりに数値引数が select フィールドに定義されています。その後、CODEOWNERS ファイル内のこれらのチームの前に @teams という識別子を付けることで参照できます。
CODEOWNERS の選択戦略は teams.yaml で定義された戦略よりも優先されます。これにより、特定のファイルが変更されたときに all を使用するなどのユースケースが可能になります。
codeowners ファイルにあるチームの例
# User @teams to prefix your team name and let CODEOWNERS know to look in
# your teams.yaml file
/apps/bitbucket/* @teams/frontend
# Just like with groups, you can select a sub-sampling of your team:
/src/frontend/* @teams/seniors
/src/important/* @teams/seniors:all # Inline strategy overrides `teams.yaml`
/src/test/* @teams/frontend @teams/backend
/src/database/* @teams/backend
# It is possible to mix teams and individual contributors, however the selection
# strategies only apply to the teams
/src/keys/*.pub @teams/SRE superuser@example.com
# It can be useful to setup a "meta-owner" that is responsible for changes to the
# teams and CODEOWNERS files
.bitbucket/* contributor1@example.com上記の設定では、src/important と src/test ディレクトリに変更を加えたプル リクエストでは、プル リクエストの作成画面に seniors チームのすべてのコントリビューター、backend チームの 1 人のコントリビューター、frontend チームの 2 人のコントリビューターがレビュアーとして追加されます。
コード所有者の設定は常にプル リクエストの宛先ブランチから読み取られます。たとえば、プル リクエストが main ブランチを対象としている場合、レビュアーは main ブランチの CODEOWNERS ファイルと teams.yaml ファイルに基づいて割り当てられます。
チームを含む CODEOWNERS ファイルの完全な例
# The CODEOWNERS file shares the same pattern matching syntax for file/directory
# names with .gitignore
# This is a comment.
# Each non-commented line consists of a file pattern followed by one or more owners.
# These owners will be the default owners for everything in
# the repository. Unless a later match takes precedence.
#
# global-owner1@example.com and global-owner2@example.com will be requested for
# review when someone opens a pull request.
#
# * global-owner1@example.com global-owner2@example.com
# Order is important; the last matching pattern takes the most
# precedence. When someone opens a pull request that only
# modifies JS files, only js-owner@example.com and not the global
# owner(s) will be requested for a review.
#
# *.js js-owner@example.com # This is an inline comment.
# This means that more specific file-level ownership rules
# often drift towards the bottom of the file. If this specific
# file is changed, Steve Driftexpert will be counted as an owner. Rather
# than js-owner as defined above.
#
# /src/pullrequests/drift.js stevedriftexpert@example.com
# Groups can be added as owners, they must be prefixed by
# the workspace name. When a group match occurs, a single
# random user from that group is chosen by default.
#
# *.js @workspace-slug/frontenders
# If something other than the default behavior for group
# matches is wanted, you can explicitly define the
# matching strategy.
# The available matching strategies are:
# random - select N random user(s) from this group
# all - select all members of this group
# least_busy - select N users(s) sorted by the number of open reviews
# Examples:
#
# Select a configurable number of users at random
#
*.py @workspace-slug/py-owners:random # same as random(1)
*.py @workspace-slug/py-owners:random(3) # 3 random users
#
# Sort reviewers by # of active PR reviews DESC and select
# a configurable number of users in that order.
#
# *.py @workspace-slug/py-owners:least_busy # Same as least_busy(1)
# *.py @workspace-slug/py-owners:least_busy(3) # least-busy 3 people
#
# Always select the entire group
#
# *.py @workspace-slug/py-owners:all
# Additionally it is possible to define codeowners "teams" by specifying
# a yaml file called `teams.yaml` in the same directory as your CODEOWNERS file.
# This allows for all of the benefits of Groups, while keeping the configuration
# for this collection of users entirely within the repository.
#
# The contents of this file should be a map of team names that have a `contributors`
# and a `reviews` key that specify the email addresses of team members and the
# the reviewer selection configuration.
#
# cat .bitbucket/teams.yaml
#
# Frontend: # Name of the team
# contributors: # Array of contributors by email address
# - user1@example.com
# - user2@example.com
# - user3@example.com
# - user4@example.com
# - user5@example.com
# - user6@example.com
# reviews: # Configuration for selecting PR reviewers
# strategy: least_busy # Reverse sort by # of open PR's they are reviewing
# select: 2 # and select the top 2 contributors
# Backend:
# contributors:
# - user7@example.com
# - user8@example.com
# reviews:
# strategy: random # Randomly sort all users
# select: 1 # and select the top 1この内容はお役に立ちましたか?