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

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

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

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

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

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

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

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

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

承認ルールを追加する

前提要件:

• プロジェクトのメンテナーロール以上を持っている必要があります。
• 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. 承認者を削除を選択します。

複数の承認ルール

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

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

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

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

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

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

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

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

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

前提要件:

• プロジェクト設定承認ルールの編集を禁止が無効になっています。
• 次のいずれかがtrueである必要があります:
  • 管理者アクセス権が必要です。
  • 自分がマージリクエストの作成者であり、プロジェクトで少なくともデベロッパーロールを持っている必要があります。
  • プロジェクトのメンテナー以上のロールを持っている必要があります。

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

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

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

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

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

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

ルールに必要な複数の承認を要求するには、APIを使用して、approvals_required属性を2以上に設定することもできます。

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

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

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

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

保護ブランチの承認

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

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

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

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

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

前提要件:

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

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

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

セキュリティ承認

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

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

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

適格な承認者

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

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

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

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

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

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

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

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

コードオーナーを承認者として

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

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

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

メンバーシップタイプ別の承認者

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

ユーザーの適格性

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

グループの適格性

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

グループ承認者

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

通常、グループは最上位のネームスペースのサブグループですが、外部グループとコラボレーションしている場合は除きます。別のグループと連携していて、そのグループのメンバーを承認者として使用したい場合は、次のいずれかを行うことができます:

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

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

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

トラブルシューティング

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

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

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

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

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

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

次に例を示します:

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

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