マージリクエスト承認ルール

承認ルールでは、マージリクエストをマージする前に必要な承認の数と、承認を行うユーザーを定義します。これらをコードオーナーと組み合わせて使用することで、機能の保守を行うグループと、特定の監視領域を担当するすべてのグループによる変更のレビューを確実にできます。

承認ルールは、次のように定義できます。

• プロジェクトのデフォルトとして。
• マージリクエストごと。

承認ルールは、次のように設定できます。

• インスタンス全体に対して。

デフォルトの承認ルールを定義しない場合、どのユーザーでもマージリクエストを承認できます。ルールを定義しない場合でも、プロジェクトの設定で必要な承認者の最小数を適用できます。

フォークからアップストリームプロジェクトなど、別のプロジェクトを対象とするマージリクエストは、ソース（フォーク）ではなく、ターゲット（アップストリーム）プロジェクトからのデフォルトの承認ルールを使用します。

ポリシーを使用して、すべてのプロジェクト（またはサブセット）に適用するようにマージリクエストの承認をグローバルに設定できます。マージリクエスト承認ポリシーでは、よりきめ細かい設定オプションを使用して、柔軟性を高めることもできます。

承認ルールを追加する

前提条件:

• プロジェクトのメンテナーまたはオーナーロールが必要です。
• GitLab.comでグループを承認者として追加するには、そのグループのメンバーであるか、グループが公開されている必要があります。

マージリクエスト承認ルールを追加するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > マージリクエストを選択します。
3. マージリクエストの承認セクションの承認ルールセクションで、承認ルールを追加を選択します。
4. 右サイドバーで、フィールドに入力します:
   • 承認が必要で、0の値はルールをオプションにし、0より大きい数値を指定すると必須ルールが作成されます。必要な承認の最大数は100です。
   • 承認者を追加から、承認を受ける資格があるユーザーまたはグループを選択します。GitLabは、マージリクエストによって変更されたファイルの以前の作成者に基づいて承認者を提案します。
5. 変更を保存を選択します。複数の承認ルールを追加できます。

承認ルールの上書きの設定によって、新しいルールが既存のマージリクエストに適用されるかどうかが決まります:

• 承認ルールの上書きが許可されている場合、これらのデフォルトルールへの変更は、ルールのターゲットブランチへの変更を除き、既存のマージリクエストには適用されません。
• 承認ルールの上書きが許可されていない場合、デフォルトルールへのすべての変更が既存のマージリクエストに適用されます。承認ルールの上書きが許可されていた期間中に以前に手動で上書きされた承認ルールは、変更されません。

承認ルールを編集する

前提条件:

• プロジェクトのメンテナーまたはオーナーロールが必要です。
• GitLab.comでグループを承認者として追加するには、そのグループのメンバーであるか、グループが公開されている必要があります。

マージリクエスト承認ルールを編集するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > マージリクエストを選択します。
3. マージリクエストの承認セクションの承認ルールセクションで、編集するルールの横にある編集を選択します。
4. 右サイドバーで、フィールドを編集します:
   • 承認が必要で、0の値はルールをオプションにし、0より大きい数値を指定すると必須ルールが作成されます。必要な承認の最大数は100です。
   • ユーザーまたはグループを削除するには、削除するグループまたはユーザーを特定し、削除（ ）を選択します。
5. 変更を保存を選択します。

承認ルールを削除する

前提条件:

• プロジェクトのメンテナーまたはオーナーロールが必要です。

マージリクエスト承認ルールを削除するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > マージリクエストを選択します。
3. マージリクエストの承認セクションで、削除するルールの横にあるゴミ箱（ ）を選択します。
4. 承認者を削除を選択します。

複数の承認ルール

マージリクエストで複数の承認ルールを適用するには、プロジェクトに複数のデフォルト承認ルールを追加します。

適格な承認者がマージリクエストを承認すると、承認者が属するすべてのルールについて、残りの承認数（承認列）が減少します:

概要については、複数の承認者ビデオを参照してください。

承認できるすべてのマージリクエストに関する通知を受け取る

承認できるマージリクエストが作成されるたびにメール通知を受け取るには:

• 通知レベルを設定をカスタムに設定し、あなたの承認が必要なマージリクエストが作成された時イベントを選択します。

マージリクエスト承認ルールを編集または上書きする

次のいずれかの方法で、プロジェクトのマージリクエスト承認ルールを上書きできます。

• 既存のマージリクエストを編集します。
• 新しいマージリクエストを作成します。

前提条件:

• プロジェクトの設定であるマージリクエストの承認ルールの編集を防ぎます。が無効になっています。
• 次のいずれかが当てはまる必要があります:
  • あなたは管理者アクセス権を持っています。
  • あなたはマージリクエストの作成者であり、プロジェクトでデベロッパー、メンテナー、またはオーナーロールを持っています。
  • あなたはプロジェクトでメンテナーまたはオーナーロールを持っています。

マージリクエストの承認者を上書きするには:

1. 新しいマージリクエストを作成するときは、承認ルールセクションまでスクロールし、マージリクエストを作成を選択する前に、目的の承認ルールを追加または削除します。
2. 既存のマージリクエストを表示する場合:
   1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
   2. 左側のサイドバーで、コード > マージリクエストを選択して、マージリクエストを見つけます。
   3. 編集を選択します。
   4. 承認ルールセクションまでスクロールします。
   5. 目的の承認ルールを追加または削除します。
   6. 変更を保存を選択します。

管理者は、マージリクエスト承認設定を変更して、ユーザーがマージリクエストの承認ルールを上書きできないようにすることができます。

ルールに必要な複数の承認を要求する

複数の承認を必要とする承認ルールを作成するには:

• ルールを作成または編集するときは、必要な承認を2以上に設定します。

ルールに複数の承認を必須とするには、マージリクエスト承認APIを使用して、approvals_required属性を2以上に設定することもできます。

オプションの承認ルールを設定する

マージリクエストの承認は、承認は評価されるが必須ではないプロジェクトではオプションにできます。承認ルールをオプションにするには:

• ルールを作成または編集するときは、必要な承認を0に設定します。

承認ルールをオプションにするには、APIを使用してプロジェクトの承認ルールを更新し、approvals_required属性を0に設定することもできます。

保護ブランチの承認

承認ルールは、デフォルトブランチなど、特定のブランチにのみ関連する場合がよくあります。特定のブランチの承認ルールを設定するには:

1. 承認ルールを作成します。
2. プロジェクトに移動し、設定 > マージリクエストを選択します。
3. マージリクエストの承認セクションで、承認ルールまでスクロールします。
4. ターゲットブランチの場合:
   • ルールをすべての保護ブランチに適用するには、すべての保護ブランチを選択します。
   • ルールを特定のブランチに適用するには、リストからそれを選択します。
5. この設定を有効にするには、Code ownerコードオーナーによる保護ブランチでの承認を必須にするに従ってください。

追加ユーザーの承認権限を有効にする

プランナーまたはレポーターロールを持つユーザーが保護ブランチにマージできるようにする前に、マージリクエストを承認する権限を付与する必要があります。一部のユーザー（マネージャーなど）は、コードをプッシュまたはマージする権限を必要としない場合がありますが、提案された作業に対する監視は依然として必要です。

プランナーまたはレポーターロールを持つユーザーは、通常の承認ルールを通じてのみマージリクエストを承認できます。コードオーナーの承認ルールでは、ユーザーがデベロッパー、メンテナー、またはオーナーロールを持っている必要があります。詳細については、承認可能な承認者を参照してください。

前提条件:

• この方法は機能しないため、All BranchesまたはAll protected branchesの設定で機能するため、特定のブランチを選択する必要があります。
• 追加されたユーザーがグループの一員であっても、共有グループは個々のユーザーではなく承認ルールに追加する必要があります。

プッシュアクセスを付与せずにこれらのユーザーの承認権限を有効にするには:

1. 保護ブランチを作成します
2. プランナーまたはレポーターロールを持ち、承認権限が必要なユーザーのために新しいグループを作成します。
3. ユーザーをグループに追加します。ユーザーはプランナー、レポーター、デベロッパー、メンテナー、またはオーナーロールを持っている必要があります。
4. プロジェクトを自分のグループと共有し、レポーター、デベロッパー、メンテナー、またはオーナーロールを付与します。
5. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
6. 設定 > マージリクエストを選択します。
7. マージリクエストの承認セクションの承認ルールセクションで:
   • 新しいルールについては、承認ルールを追加を選択し、保護ブランチをターゲットにします。
   • 既存のルールについては、編集を選択し、保護ブランチをターゲットにします。
8. 右側のサイドバーの承認者を追加で、作成したグループを選択します。
9. 変更を保存を選択します。

セキュリティ承認

マージリクエスト承認ポリシーを使用すると、マージリクエストとデフォルトブランチの脆弱性の状態に基づいてセキュリティ承認を定義できます。各セキュリティポリシーの詳細は、マージリクエスト設定のセキュリティ承認セクションに表示されます。

セキュリティ承認ルールは、パイプラインが完了するまですべてのマージリクエストに適用されます。セキュリティ承認ルールの適用により、ユーザーはセキュリティスキャンが実行される前にコードをマージできなくなります。パイプラインが完了すると、セキュリティ承認ルールがチェックされ、セキュリティ承認がまだ必要かどうかが判断されます。パイプライン内のスキャナーがイシューを特定し、セキュリティ承認が必要な場合、マージリクエストにボットコメントが生成され、続行するために必要な手順が示されます。

これらのポリシーは、セキュリティポリシーエディタで作成および編集されます。

適格な承認者

プロジェクトの承認者として承認されるには、ユーザーは次のいずれかの直接メンバーである必要があります:

• あなたのプロジェクト。
• あなたのプロジェクトのグループ。
• あなたのプロジェクトのグループのいずれかの親グループ。
• あなたのプロジェクトと共有されている別のグループ。
• あなたのプロジェクトのグループまたはそのグループのいずれかの親と共有されている別のグループ。
• 承認者として追加されたグループ。

デベロッパーロールを持つユーザーは、次のいずれかに該当する場合、マージリクエストを承認できます:

• プロジェクトまたはマージリクエストレベルで承認者として追加されたユーザー。
• マージリクエストで変更されたファイルのCode ownerコードオーナーであるユーザー。

プランナーまたはレポーターロールを持つユーザーは、次のすべてが当てはまる場合にのみ承認できます:

• ユーザーは、プロジェクトと共有されているグループの一員である必要があります。グループはレポーター、デベロッパー、メンテナー、またはオーナーロールを持っている必要があります。
• プランナーおよびレポーターロールを持つユーザーの承認権限が有効になっている。

マージリクエストのレビューに参加したユーザーを表示するために、マージリクエストの承認ウィジェットには、コメント投稿者列が表示されます。この列には、マージリクエストにコメントした、適格な承認者が一覧表示されます。これにより、作成者とレビュアーは、マージリクエストの内容に関する質問について誰に連絡すればよいかを特定できます。

必要な承認数が承認者数より多い場合、プロジェクトのデベロッパー、メンテナー、またはオーナーロールを持つ他のユーザーからの承認は、ユーザーが承認ルールに明示的にリストされていなくても、必要な承認数を満たすものとしてカウントされます。

Code ownersを承認者として

コードオーナーをリポジトリに追加すると、ファイルのオーナーがプロジェクトで適格な承認者になります。このマージリクエスト承認ルールを有効にするには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > マージリクエストを選択します。
3. マージリクエストの承認セクションの承認ルールセクションで、すべての対象ユーザールールを見つけます。
4. 承認が必要列に、必要な承認の数を入力します。

保護ブランチに対してコードオーナーの承認を要求することもできます。

メンバーシップの種類による承認者

次の表は、メンバーシップの種類が承認ルールとコードオーナーの両方の適格性にどのように影響するかを示しています。

ユーザーの適格性

個々のユーザーを承認ルールの承認者として割り当てるか、CODEOWNERSファイルで@usernameのような参照ユーザーを割り当てる場合:

グループの適格性

CODEOWNERSファイルで@group-nameのように、グループを承認ルールの承認者として割り当てるか参照グループとして割り当てる場合、承認可能なグループの直接メンバーのみが承認を提供できます:

グループ承認者

ユーザーのグループを承認者として追加できます。このグループのすべての直接のメンバーは、ルールを承認できます。継承されたメンバーは、ルールを承認できません。

通常、グループは最上位のネームスペースのサブグループですが、外部グループとコラボレーションしている場合は除きます。他のグループと共同作業しており、そのグループのメンバーを承認者として使用したい場合は、次のいずれかの方法があります:

• プロジェクトへのアクセスを共有します。
• プロジェクトのグループへのアクセスを共有します。これにより、外部グループはプロジェクトのグループ内のすべてのプロジェクトに対する承認アクセス権を得ます。

承認者グループにおけるユーザーのメンバーシップは、次の方法で個々の承認権限を決定します:

• 継承されたメンバーは、承認者とは見なされません。直接のメンバーのみがマージリクエストを承認できます。
• 後で個人承認者としても追加される、グループ承認者グループのユーザーは、2人ではなく、1人の承認者としてカウントされます。
• マージリクエストの作成者は、デフォルトでは、自分のマージリクエストの適格な承認者としてカウントされません。この動作を変更するには、Prevent merge request creator approvalプロジェクトの設定を無効にします。
• デフォルトでは、マージリクエストのコミッターはマージリクエストを承認できます。この動作を変更するには、コミッターの承認を禁止プロジェクト設定を有効にします。

トラブルシューティング

承認ルール名は空白にできない

この検証エラーの回避策として、APIを使用して承認ルールを削除できます。

1. プロジェクトのすべての承認ルールをリストします。
2. ルールを削除します。

この検証エラーの詳細については、イシュー285129をお読みください。

グループは、プロジェクトに対する明示的または継承されたデベロッパーロールを必要とする

承認を処理するために作成されたグループは、レビューを必要とするプロジェクトとは異なるプロジェクト階層の領域に作成される場合があります。この場合、グループのメンバーは、アクセス権がないため、マージリクエストを承認する権限がない可能性があります。

例:

以下のグループ構造では、プロジェクト1はサブグループ1に属し、サブグループ4にはユーザーがいます。

プロジェクト1は、プロジェクトの承認ルールを設定しており、サブグループ4を承認者として割り当てています。マージリクエストが作成されると、サブグループ4の承認者が、適格な承認者のリストに表示されます。ただし、サブグループ4のユーザーはマージリクエストを表示する権限がないため、404エラーが返されます。メンバーシップを付与するには、グループをプロジェクトメンバーとして招待する必要があります。これで、サブグループ4のユーザーが承認できるようになりました。