株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

GitとCI/CDに関する知識ゼロのSEが、GitLabでマージリクエストの承認ルール機能をちょっとだけ試す (2023/07/05 更新)

2022/08/23 一部の図の背景が透過されていて見づらかったので、修正致しました。
2023/07/05 GitLab.com Enterprise Edition 16.2.0-pre での手順と画面に更新しました。

皆様こんにちは。SEの小池と申します。

今回はGitLabのUltimateにしかない機能、マージリクエスト承認 (Merge request approvals) の 承認ルール (Merge request approval rules) を試してみます
たまには有償版の機能の紹介をしないとマーケティング部からなんか言わr…何でもありません。

本記事の対象の方

  • GitLabのUltimate限定機能であるマージリクエスト承認ルール (Merge request approval rules) のをちょっとだけ使ってみたい方。

今回のブログのゴール

このブログのゴールはこちらです。


今回のゴール
  • マージリクエスト承認の承認ルールを触ってみる。

このブログをお読みいただくにあたっての事前ご連絡事項

  • 本記事は GitLabのSaaS版 (GitLab.com) のEnterprise Edition 16.2.0-pre (Ultimate) における仕様をベースに記載しております。それ以外のエディションやバージョンではこの記事に記載の通りではない可能性がございます。
  • 本記事の操作説明と画面ショットはGitLabのローカライズを日本語にした状態で説明しております。それ以外の言語をご利用の方は適宜読み替えてください。
  • 本記事はGitやCI/CDに関する知識ゼロのSEによるなんちゃって記事です。GitLabのディープな使用法についてはGitLabの公式オンラインドキュメント (こちら) をご参照ください。

マージリクエスト承認機能の概要

まず、マージリクエスト承認 (Merge request approvals) は簡単に言うと、マージリクエストのマージ前の承認において、明示的な承認者や承認を得るべき人数等を指定できる機能です。
参考 : Merge request approvals | GitLab

GitLabにはマージリクエストにおけるマージの前に、「承認」という処理があります。
「承認」されないと、マージリクエストでマージボタンが表示されません。

必要な「承認」を得られると、このマージリクエストをマージできるようになります。

デフォルトでは、ロールDevelopers以上の権限を持つメンバーは「承認」することができます (マージリクエストを作成したユーザーは除く) 。
ですがプロジェクトや組織によっては、明示的にマージリクエスト内でリーダークラスの方の承認を2人以上得ることを必須としたい…等のご要件があるかと存じます。
そういった細かい承認のご要件を満たせるのがこのマージリクエスト承認 (Merge request approvals) です。

マージリクエスト承認を設定する方法はいくつかありますが、その中でもこのブログでは Ultimate 限定機能である 承認ルール を試します。
参考 : Merge request approval rules | GitLab

実際に本ブログでは下図のようなマージリクエストの承認ルールを作成します。

なお、マージリクエスト承認 (Merge request approvals) の承認ルール (Merge request approval rules) は Ultimate でしか利用できない機能です。
手元にUltimateのGitLabがないけれど承認ルール (Merge request approval rules) をお試しになりたい場合は、トライアルのお申し込みをご検討ください。

マージリクエスト承認を試すためのシナリオ

マージリクエスト承認を試すための簡単なシナリオを用意しました。

GitLabを利用する企業Aは、特定のプロジェクトのマージリクエストで以下のご要件をお持ちであると仮定します。

【企業Aのご要件】
  • 開発グループのメンバーのうち2名から承認を得ることを必須とする。
  • 開発グループのリーダーとサブリーダーのどちら1名から承認を得ることを必須とする。
  • 上記2つの条件はターゲットブランチが main のマージリクエストのみ対象とする。
  • ターゲットブランチ問わず、コミットしたユーザー自身による承認を可能とする。
  • 今回のブログでは上記の架空のご要件を満たすように、マージリクエスト承認 (Merge request approvals) を設定していきます。
    また、今回は仮に以下を満たしていると仮定します。

    【企業Aの前提】
  • 親グループには開発グループメンバー全員が過不足なく含まれている。
  • 開発経験のない筆者が適当に考えた架空のご要件なので、開発現場の方からすると「ありえねぇよ!」なルールだったらすみません。

    マージリクエスト承認の設定

    今回は例として、プロジェクトに承認ルールを設定していきます。

    対象となるプロジェクトのページをロールowner もしくは maintainer を持ったユーザーで開きます。
    そして、[設定] > [マージリクエスト] を開きます。

    [マージリクエスト承認] の [承認ルールの追加] をクリックすることで、新しい承認ルールを追加できます。
    なお、[マージリクエスト承認]がそもそも表示されていない場合、マージリクエスト承認機能 (Merge request approvals) を使えないFreeライセンスを使用している可能性があります。ご利用中のライセンスをご確認ください。

    承認ルールで設定できる項目は、以下の4つです。
    これらをうまく組み合わせながら、先述したシナリオのご要件を実現していきます。

    表1. 承認ルールの設定項目
    設定項目 概要
    ルール名 このルールの名前。マージリクエストの画面上に表示される。
    ターゲットブランチ ここで指定したブランチがターゲットブランチになっているマージリクエストにのみ、このルールが適用される。
    Approvals required このルールで必要な承認者の数。
    承認者を追加 このルールの承認者となるユーザーを指定する。親グループ や 他のグループを指定することも可能。

    設定例:開発メンバー2名による承認

    まず、ご要件の1, 3点目を実現する設定をします。

    【企業Aのご要件】
  • 開発グループのメンバーのうち2名から承認を得ることを必須とする。
  • 開発グループのリーダーとサブリーダーのどちら1名から承認を得ることを必須とする。
  • 上記2つの条件はターゲットブランチが main のマージリクエストのみ対象とする。
  • ターゲットブランチ問わず、コミットしたユーザー自身による承認を可能とする。
  • 先ほどの [マージリクエスト承認] セクションで [承認ルールの追加] をクリックし、新しいルールを以下の設定で作成します。
    設定したら、[承認ルールの追加] をクリックします。

    表2. 開発メンバー2名による承認のルール設定値
    設定項目 設定値
    ルール名 任意。例として、「メンバー2名による承認」とする。
    ターゲットブランチ main
    Approvals required 2
    承認者を追加 このプロジェクトが所属する親グループを指定する。

    承認ルールの一覧に追加したルールが表示されていることを確認します。

    設定例:リーダー等、特定メンバー1名以上による承認

    続いて、ご要件の2, 3点目を実現する設定をします。

    【企業Aのご要件】
  • 開発グループのメンバーのうち2名から承認を得ることを必須とする。
  • 開発グループのリーダーとサブリーダーのどちら1名から承認を得ることを必須とする。
  • 上記2つの条件はターゲットブランチが main のマージリクエストのみ対象とする。
  • ターゲットブランチ問わず、コミットしたユーザー自身による承認を可能とする。
  • 前の手順と同様、[マージリクエスト承認] セクションで [承認ルールの追加] をクリックし、新しいルールを以下の設定で作成します。
    設定したら、[承認ルールの追加] をクリックします。

    表3. 開発グループのリーダーとサブリーダーのどちら1名から承認のルール設定値
    設定項目 設定値
    ルール名 任意。例として、「リーダー または サブリーダーによる承認」とする。
    ターゲットブランチ main
    Approvals required 1
    承認者を追加 リーダーとサブリーダーを明示的に追加する。

    承認ルールの一覧に追加したルールが表示されていることを確認します。

    設定例:コミットしたユーザー自身による承認を可能とする

    最後に、ご要件の4点目について。

    【企業Aのご要件】
  • 開発グループのメンバーのうち2名から承認を得ることを必須とする。
  • 開発グループのリーダーとサブリーダーのどちら1名から承認を得ることを必須とする。
  • 上記2つの条件はターゲットブランチが main のマージリクエストのみ対象とする。
  • ターゲットブランチ問わず、コミットしたユーザー自身による承認を可能とする。
  • 実はGitLabはデフォルトでコミットしたユーザー自身での承認が可能なので、これについては特に設定することはありません。
    なおこの設定は、対象プロジェクトの [設定] > [マージリクエスト] > [マージリクエスト承認] の [承認の設定] という項目で、[コミットを追加したユーザーによる承認を防ぎます。] にチェックがデフォルトで入っていないため、このような挙動になります。
    参考 : Merge request approval settings | GitLab

    もし今回のシナリオのご要件とは逆に、コミットしたユーザー自身での承認を不可としたい場合は、上記の [コミットを追加したユーザーによる承認を防ぎます。] にチェックを入れてください。

    承認ルール設定後のテスト

    承認ルールを設定後、意図する通りに稼働するか確認しましょう。

    ターゲットブランチをmainとした任意のマージリクエストを作成してみると・・・
    図の通り、作成したルールが表示され、承認に必要な人数もちゃんと設定されていることがわかります。

    次に、ターゲットブランチをmain以外にしたマージリクエストを作成してみると・・・
    図の通り、今回作成した承認ルールは適用されず、デフォルトの承認ルールが表示されていることがわかります。

    以上のように、架空のご要件をマージリクエスト承認 (Merge request approvals) の承認ルールを使って実現することができました。

    余談 : マージリクエストを作成したユーザー自身による承認

    GitLabはデフォルトでは、マージリクエストを作成したユーザーがそのマージリクエストの「承認」をすることができません。
    もしこの設定を変更したい場合は、今回と同様に対象プロジェクトの [設定] > [マージリクエスト] > [マージリクエスト承認] > [承認の設定] から変更できます。

    上の画面の [承認の設定] の [作者自身による承認を防止します。] のチェックを外すと、自分自身で作成したマージリクエストの承認が可能になります。

    最後に

    この度はGitもCI/CDもよくわかっていないど素人SEによるGitLab検証ブログをお読みいただき、誠にありがとうございます。
    このブログの目標は以下のとおりでしたが、皆さまはいかがでしたでしょうか。

    今回のゴール
    • マージリクエスト承認の承認ルールを触ってみる。

    マージリクエスト承認機能 (Merge request approvals) は今回ご紹介いたしました "承認ルール" 以外での設定方法もあるため、意外と奥が深い機能となっております。
    この記事がGitLabを触り始めた方の一助となれば幸いにございます。


    GitLabに関するお問い合わせは、以下のフォームからお願い致します。
    GitLab製品 お問い合わせ

    今までのGitLabの検証ブログはこちらです。
    GitLab カテゴリーの記事一覧 - ネットワールド らぼ

    GitLab操作デモ動画 (基本編) を作ってみました。(音声の録音は自宅でiPhoneのボイスメモ使うという超低クオリティですが…。)
    つたない内容ではありますが、ご興味がおありでしたら是非ご視聴いただければと存じます。

    www.youtube.com