コードオーナー
13.9でGitLab Premiumに移行しました。
コードオーナー機能を使って、プロジェクトのコードベースの特定の部分の専門知識を持つ人を定義します。リポジトリ内のファイルやディレクトリのオーナーを定義します：
- オーナーに変更を承認させることができます。保護されたブランチとコードオーナーを組み合わせて、エキスパートが保護されたブランチにマージする前にマージリクエストを承認することを要求します。
-
オーナーの識別コードオーナーの名前は、所有するファイルやディレクトリに表示されます：
コードオーナーをマージリクエスト承認ルール（任意または必須）と組み合わせて使用することで、柔軟な承認ワークフローを構築できます：
- コードオーナーを使用して品質を確保します。リポジトリ内の特定のパスについて、ドメインの専門知識を持つユーザーを定義します。
- 承認ルールを使用して、リポジトリ内の特定のファイルパスに対応しない専門領域を定義します。承認ルールは、マージリクエスト作成者をフロントエンド開発者やセキュリティチームなどの適切なレビュアーに導くのに役立ちます。
使用例：
| 種類 | 名前 | スコープ | コメント |
|---|---|---|---|
| 承認者ルール | UX | すべてのファイル | ユーザーエクスペリエンス(UX) チームメンバーが、プロジェクトで行われたすべての変更のユーザーエクスペリエンスをレビューします。 |
| 承認者ルール | セキュリティ | すべてのファイル | セキュリティチームのメンバが、すべての変更に脆弱性がないかレビューします。 |
| コードオーナーの承認ルール | フロントエンドコードスタイル |
*.css ファイル | フロントエンドエンジニアは、CSSファイルの変更がプロジェクトのスタイル標準に準拠しているかレビューします。 |
| コードオーナーの承認ルール | バックエンドコードレビュー |
*.rb ファイル | バックエンドエンジニアはRubyファイルのロジックとコードスタイルをレビューします。 |
ファイルやディレクトリのコードオーナーの表示
ファイルまたはディレクトリのコードオーナーを表示します：
- 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
- Code > Repositoryを選択します。
- コードオーナーを表示したいファイルまたはディレクトリに移動します。
- オプションです。ブランチまたはタグを選択します。
GitLabはページ上部にコードオーナーを表示します。
コードオーナーの設定
- お好きな場所に
CODEOWNERSファイルを作成してください。 -
Code Ownersの構文リファレンスに従って、ファイルにルールを定義してください。いくつかの提案があります：
- すべての承認者の承認ルールを設定します。
- 保護ブランチでコードオーナーの承認を必要とします。
- 変更をコミットし、GitLab にプッシュします。
コードオーナーファイル
CODEOWNERS ファイル（拡張子なし）は、リポジトリ内の特定のファイルやディレクトリに責任を持つユーザーや共有グループを指定します。
各リポジトリは1つのCODEOWNERS ファイルを CODEOWNERS使用します。CODEOWNERS GitLab はリポジトリ内のこれらの場所をこの順番でチェックします。最初に CODEOWNERS見つかったファイルが使われ、それ以外は無視されます：
- ルートディレクトリ内：
./CODEOWNERS. -
docsディレクトリ内:./docs/CODEOWNERS. -
.gitlabディレクトリ内:./.gitlab/CODEOWNERS.
コードオーナーとしてのグループの追加
GitLab 13.0でグループとサブグループの階層サポートが導入されました。
グループやサブグループのメンバーをコードオーナーに設定するには：
CODEOWNERS ファイルに、以下のいずれかのパターンに従ったテキストを入力します：
# All group members as Code Owners for a file
file.md @group-x
# All subgroup members as Code Owners for a file
file.md @group-x/subgroup-y
# All group and subgroup members as Code Owners for a file
file.md @group-x @group-x/subgroup-y
グループの継承と適格性
GitLab 13.0でグループとサブグループの階層サポートが導入されました。
この例では:
-
親グループ X(
group-x) がプロジェクト A を所有しています。 -
親グループ XはサブグループY も所有しています (
group-x/subgroup-y)。 - サブグループYはプロジェクトBを所有しています。
対象となるコードオーナーは以下の通り：
- プロジェクトA：プロジェクトAは サブグループYに属さないため、グループXのメンバーのみ。
- プロジェクトB：グループXと サブグループYの両方のメンバー。
親グループのプロジェクトにサブグループを招待
サブグループ Yをプロジェクト Aに招待し、そのメンバーもコードオーナーになることができます。
サブグループ Yをプロジェクト A に招待せず、コードオーナーにした場合、サブグループ Y のマージリクエストの承認者は任意になります。
親グループへのサブグループの招待
サブグループ Yをプロジェクト Aの親グループに招待することはサポートされていません。サブグループ Yをコードオーナーに設定するには、このグループをプロジェクト自体に直接招待してください。
より具体的に定義されたファイルやディレクトリに対して、より具体的なオーナーを定義することができます。
ファイルまたはディレクトリがCODEOWNERS ファイルの複数のエントリと一致する場合、そのファイルまたはディレクトリに最後に一致したパターンのユーザーが使用されます。このため、エントリを適切な方法で並べ替えると、より具体的に定義されたファイルやディレクトリに対して、より具体的なオーナーを定義することができます。
例えば、CODEOWNERS ファイルは次のようになります：
# This line would match the file terms.md
*.md @doc-team
# This line would also match the file terms.md
terms.md @legal-team
terms.md のコード・オーナーは@legal-team となります。
セクションを使用する場合、各セクションのファイルまたはディレクトリに一致する最後のパターンが使用されます。例えば、CODEOWNERS ファイルでセクションを使用する場合：
[README Owners]
README.md @user1 @user2
internal/README.md @user4
[README other owners]
README.md @user3
ルート・ディレクトリのREADME.md のコード・オーナーは、@user1 、@user2、@user3です。internal/README.md のコード・オーナーは@user4 と@user3です。
1つのセクションにつき1つのCODEOWNERSパターンのみがファイルパスにマッチします。
コードオーナーをセクションに分類して整理します。
コードオーナーを名前付きのセクションにまとめることができます。
セクションを共有ディレクトリに使うことで、複数のチームがレビュアーになることができます。
CODEOWNERS ファイルにセクションを追加するには、カッコ内にセクション名を入力し、その後にファイルまたはディレクトリー、ユーザー、グループ、サブグループを入力します：
[README Owners]
README.md @user1 @user2
internal/README.md @user2
マージリクエストウィジェットの各コードオーナーは、ラベルの下に表示されます。次の図は、グループと ドキュメントのセクションを示しています：
セクションのデフォルトオーナーの設定
セクション内の複数のファイルパスが同じオーナーを共有する場合、セクションにデフォルトのコードオーナーを定義します。特定の行でセクションのデフォルトを上書きしない限り、そのセクション内のすべてのパスはこのデフォルトを継承します。
デフォルトのオーナーは、ファイル・パスに特定のオーナーが指定されていない場合に適用されます。ファイルパスの横に定義された特定のオーナーが、デフォルトのオーナーを上書きします：
[Documentation] @docs-team
docs/
README.md
[Database] @database-team
model/db/
config/db/database-setup.md @docs-team
この例では:
-
@docs-teamは、Documentationセクションのすべての項目を所有しています。 -
@database-teamconfig/db/database-setup.mdを除くDatabaseセクションのすべてのアイテムを所有します。@docs-teamにはオーバーライドが割り当てられています。
デフォルトのオーナーとオプションのセクションおよび必要な承認者の構文を組み合わせるには、デフォルトのオーナーを最後に置きます：
[Documentation][2] @docs-team
docs/
README.md
^[Database] @database-team
model/db/
config/db/database-setup.md @docs-team
名前が重複するセクション
複数のセクションが同じ名前の場合、それらは結合されます。また、セクションの見出しは大文字と小文字を区別しません。例えば
[Documentation]
ee/docs/ @docs
docs/ @docs
[Database]
README.md @database
model/db/ @database
[DOCUMENTATION]
README.md @docs
このコードでは、Documentationセクションヘッダの下に 3 つのエントリがあり、Database の下に 2 つのエントリがあります。DocumentationとDOCUMENTATIONセクションで定義されたエントリは、最初のセクションの大文字と小文字を区別して結合されます。
コード・オーナー・セクションのオプション化
GitLab 13.8 で導入されました。
コードオーナーファイルでオプショナルセクションを指定することができます。セクション名の前にキャレット^ を付けると、そのセクション全体がオプショナルとして扱われます。オプショナルセクションを使うことで、コードベースの様々な部分の責任者を指定することができます。この方法は、頻繁に更新されるけれども厳しいレビュアーは必要ないプロジェクトの部分に対して、より緩やかなポリシーを提供します。
この例では、[Go] セクションはオプションです：
[Documentation]
*.md @root
[Ruby]
*.rb @root
^[Go]
*.go @root
オプションのコードオーナーセクションは、マージリクエストで承認ルールエリアの下に表示されます：
あるセクションがファイル内で重複していて、一方がオプションとマークされ、もう一方がオプションとマークされていない場合、そのセクションは必須となります。
CODEOWNERS ファイルのオプションのセクションは、マージリクエストを使って変更が提出されたときのみオプションとして扱われます。変更が protected ブランチに直接提出された場合は、セクションがオプションとしてマークされていても、コードオーナーの承認者が必要です。
コードオーナーからの複数の承認を必要とします。
GitLab 15.9 で導入されました。
マージリクエストの承認ルールエリアで、コードオーナーセクションに複数の承認を求めることができます。セクション名にn 括弧内の n数字を追加します。n これは n、このセクションのコードオーナーの承認者をn 要求 nします。n の有効なエントリは整数であることに注意してください。≥ 1.[1] はデフォルトであるため省略可能です。n の無効な値は1として扱われます。
Settings > Repository > Protected branches でRequire approval from code owners が有効になっていることを確認してください。そうでない場合、コードオーナーの承認者はオプションになります。
この例では、[Documentation] セクションに 2 つの承認者が必要です：
[Documentation][2]
*.md @tech-writer-team
[Ruby]
*.rb @dev-team
承認ルール」エリアの「Documentation コードオーナー」セクションには、2 つの承認が必要であることが表示されます：
プッシュ許可
プッシュを許可されているユーザーは、自分の変更に対してマージリクエストを作成するか、ブランチに直接プッシュするかを選択できます。ユーザーがマージリクエストプロセスをスキップした場合、マージリクエストに組み込まれているブランチ保護機能やコードオーナーの承認もスキップされます。
この権限は、自動化(内部ユーザー) やリリースツールに関連するアカウントによく与えられます。
プッシュ許可権限を_持たない_ユーザーからのすべての変更は、マージリクエストを経由しなければなりません。
テクニカルリソース
トラブルシューティング
Code Ownersのエラー処理方法については、Code Ownersのリファレンスを参照してください。
オプションとして表示される承認者
コードオーナーの承認ルールは、以下の条件のいずれかが真である場合、オプションとなります：
- ユーザーまたはグループがプロジェクトのメンバーでない場合。コードオーナーは親グループから継承できません。
- 保護ブランチのコードオーナー承認者が設定されていません。
- セクションはオプションとしてマークされています。
承認者は表示されません。
コードオーナーの承認ルールは、マージリクエストが作成されたときにのみ更新されます。CODEOWNERS ファイルを更新する場合は、マージリクエストを閉じて、新しいファイルを作成してください。
承認者として表示されないユーザー
以下の条件に当てはまるユーザーは、コードオーナー・マージリクエストの承認者として表示されない場合があります：
- ルールによって特定のユーザーがマージリクエストを承認できない場合。プロジェクトのマージリクエスト承認設定を確認してください。
- コード所有者グループの可視性が非公開で、現在のユーザーはコード所有者グループのメンバーではありません。
- 現在のユーザーは、内部の Code Owner グループへの権限を持っていない外部ユーザーです。
承認ルールが無効です。GitLab はこのルールを自動的に承認し、マージリクエストをブロック解除しました。
承認ルールがプロジェクトの直接のメンバーではないコードオーナーを使用している場合、このメッセージが表示されることがあります。そのグループまたはユーザーがプロジェクトに招待されていることを確認してください。