マージリクエストパイプライン
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
マージリクエストのソースブランチに変更を加えるたびに実行されるよう、パイプラインを設定できます。
このタイプのパイプラインはマージリクエストパイプラインと呼ばれ、次の場合に実行されます:
- 1つ以上のコミットを含むソースブランチから新しいマージリクエストを作成する。
- マージリクエストのソースブランチに新しいコミットをプッシュする。
- マージリクエストのパイプラインタブに移動し、パイプラインの実行を選択する。
さらに、マージリクエストパイプラインには、以下の特徴があります:
- より多くの定義済み変数にアクセスできる。
- 必要に応じて保護された変数やRunnerにアクセスできる。
これらのパイプラインは、パイプラインリストにmerge requestラベルを表示します。
マージリクエストパイプラインは、ターゲットブランチの内容を無視して、ソースブランチの内容のみで実行されます。ソースブランチとターゲットブランチのマージ結果をテストするパイプラインを実行するには、マージ結果パイプラインを使用します。
前提要件
マージリクエストパイプラインを使用するには:
- プロジェクトの
.gitlab-ci.ymlファイルに、マージリクエストパイプラインで実行されるジョブが設定されている必要があります。 - マージリクエストパイプラインを実行するには、ソースプロジェクトのデベロッパーロール以上が必要です。
- リポジトリは、外部リポジトリではなく、GitLabリポジトリである必要があります。
マージリクエストパイプラインにジョブを追加する
rulesキーワードを使用して、ジョブをマージリクエストパイプラインで実行するように設定します。次に例を示します:
job1:
script:
- echo "This job runs in merge request pipelines"
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'workflow: rulesキーワードを使用して、パイプライン全体をマージリクエストパイプラインで実行するように設定することもできます。次に例を示します:
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
job1:
script:
- echo "This job runs in merge request pipelines"
job2:
script:
- echo "This job also runs in merge request pipelines"一般的なworkflowの例については、以下を参照してください:
セキュリティスキャンツールをマージリクエストパイプラインで使用するには、CI/CD変数AST_ENABLE_MR_PIPELINESまたはlatestテンプレートエディションを使用します。
フォークしたプロジェクトで使用する
フォークで作業する外部のコントリビューターは、親プロジェクト内にパイプラインを作成できません。
フォークから親プロジェクトに送信されたマージリクエストは、次のパイプラインをトリガーします:
- 親(ターゲット)プロジェクトではなく、フォーク(ソース)プロジェクトで作成および実行される。
- フォークプロジェクトのCI/CD設定、リソース、およびプロジェクトCI/CD変数を使用する。
フォークのパイプラインは、親プロジェクト内でフォークバッジとともに表示されます。
親プロジェクトでパイプラインを実行する
親プロジェクトのプロジェクトメンバーは、フォークプロジェクトから送信されたマージリクエストに対して、マージリクエストパイプラインをトリガーできます。このパイプラインの特徴は、次のとおりです:
- フォーク(ソース)プロジェクトではなく、親(ターゲット)プロジェクトで作成および実行される。
- フォークプロジェクトのブランチに存在するCI/CD設定を使用する。
- 親プロジェクトのCI/CD設定、リソース、およびプロジェクトCI/CD変数を使用する。
- パイプラインをトリガーする親プロジェクトメンバーの権限を使用する。
フォークプロジェクトのMRでパイプラインを実行し、マージ後のパイプラインが親プロジェクトで正常に完了することを確認します。さらに、フォークプロジェクトのRunnerを信頼できない場合、親プロジェクトでパイプラインを実行すれば、親プロジェクトの信頼できるRunnerが使用されます。
フォークからのマージリクエストには、マージ前であってもパイプラインの実行時に親プロジェクトのシークレットを盗もうとする悪意のあるコードが含まれている可能性があります。レビュアーは、パイプラインをトリガーする前に、マージリクエストの変更を慎重に確認してください。APIまたは/rebaseクイックアクションでパイプラインをトリガーした場合を除き、GitLabは警告を表示し、ユーザーはパイプラインを実行する前に承認する必要があります。それ以外の場合、警告は表示されません。
前提要件:
- 親プロジェクトの
.gitlab-ci.ymlファイルは、マージリクエストパイプラインでジョブを実行するように設定されている必要があります。 - CI/CDパイプラインを実行する権限を持つ、親プロジェクトのメンバーである必要があります。ブランチが保護されている場合、追加の権限が必要になることがあります。
- パイプラインを実行するユーザーがフォークプロジェクトを参照できる必要があります。そうでない場合、マージリクエストにパイプラインタブは表示されません。
UIを使用して、フォークプロジェクトからのマージリクエストに対して親プロジェクトでパイプラインを実行するには、次のようにします:
- マージリクエストで、パイプラインタブに移動します。
- パイプラインの実行を選択します。警告を読んで承認する必要があります。そうしないと、パイプラインは実行されません。
フォークプロジェクトからのパイプラインを防止する
ユーザーが親プロジェクトでフォークプロジェクトの新しいパイプラインを実行できないようにするには、プロジェクトAPIを使用して、ci_allow_fork_pipelines_to_run_in_parent_project設定を無効にします。
設定が無効になる前に作成されたパイプラインには影響せず、引き続き実行されます。古いパイプラインでジョブを再実行すると、ジョブはパイプラインの初回作成時と同じコンテキストを使用します。
利用可能な定義済み変数
マージリクエストパイプラインを使用する場合は、以下を使用できます:
保護された変数とRunnerへのアクセスを制御する
マージリクエストパイプラインから、保護されたCI/CD変数と保護されたRunnerへのアクセスを制御できます。
マージリクエストパイプラインがこれらの保護されたリソースにアクセスできるのは、マージリクエストのソースブランチとターゲットブランチの両方が保護されている場合のみです。また、パイプラインをトリガーするユーザーには、マージリクエストのターゲットブランチに対するプッシュ/マージアクセス権が必要です。マージリクエストパイプラインがこれらの保護されたリソースにアクセスできるのは、ソースブランチとターゲットブランチが同じプロジェクトに属している場合のみです。リポジトリのフォークからのマージリクエストパイプラインは、これらの保護されたリソースにアクセスできません。
前提要件:
- プロジェクトのメンテナーロールが必要です。
保護された変数とRunnerへのアクセスを制御するには、次のようにします:
- 設定 > CI/CDに移動します。
- 変数を展開します。
- マージリクエストパイプライン内で保護されたリソースへのアクセスで、マージリクエストパイプラインが保護された変数やRunnerにアクセスすることを許可するオプションをオンまたはオフにします。