プラン : Free、Premium、Ultimate 提供形態 : GitLab.com、GitLab Self-Managed、GitLab Dedicated このドキュメントでは、GitLabの .gitlab-ci.yml ファイルの設定オプションについて説明します。このファイルでは、パイプラインを構成するCI/CDジョブを定義します。 基本的なCI/CDの概念 をすでに理解している方は、 シンプル または 複雑 なパイプラインの構築手順を示すチュートリアルに沿って、独自の .gitlab-ci.yml ファイルを作成してみてください。 さまざまな例については、 GitLab CI/CDの例 を参照してください。 エンタープライズで使用される大規模な .gitlab-ci.yml ファイルを確認するには、 gitlab の .gitlab-ci.yml ファイル を参照してください。 .gitlab-ci.yml ファイルを編集しているときは、 CI Lint ツールでこのファイルを検証できます。 GitLab CI/CDの設定はYAML形式を使用するため、キーワードの順序は特に指定がない限り重要ではありません。 より動的なパイプライン設定オプションについては、 CI/CD式 を使用してください。 GitLab CI/CDパイプラインの設定には、次の要素が含まれます。 パイプラインの動作を設定する グローバルキーワード : キーワード 説明 default ジョブキーワードに対するカスタムデフォルト値。 include 他のYAMLファイルから設定をインポートします。 stages パイプラインステージの名前と順序。 variables パイプラインのすべてのジョブのデフォルトCI/CD変数を定義します。 workflow 実行するパイプラインのタイプを制御します。 パイプラインの動作を設定する グローバルキーワード : ヘッダーキーワード キーワード 説明 spec 外部設定ファイルの仕様を定義します。 ジョブキーワード を使用して設定される ジョブ : キーワード 説明 after_script ジョブの後に実行される一連のコマンドをオーバーライドします。 allow_failure ジョブの失敗を許容します。ジョブが失敗してもパイプライン全体の失敗とはなりません。 artifacts 成功時にジョブに添付されるファイルとディレクトリのリスト。 before_script ジョブの前に実行される一連のコマンドをオーバーライドします。 cache 後続の実行間でキャッシュされるファイルのリスト。 coverage 指定されたジョブのコードカバレッジ設定。 dast_configuration ジョブレベルでDASTプロファイルの設定を使用します。 dependencies アーティファクトのフェッチ元のジョブのリストを指定することで、特定のジョブに渡されるアーティファクトを制限します。 environment ジョブのデプロイ先の環境の名前。 extends このジョブが継承する設定エントリ。 identity アイデンティティフェデレーションを使用したサードパーティサービスの認証を行います。 image Dockerイメージを使用します。 inherit すべてのジョブが継承するグローバルデフォルトを選択します。 interruptible より新しい実行によってジョブが冗長になった場合に、ジョブをキャンセルできるかどうかを定義します。 manual_confirmation 手動ジョブのカスタム確認メッセージを定義します。 needs ステージの順序よりも早い時点でジョブを実行します。 pages GitLab Pagesで使用するためにジョブの結果をアップロードします。 parallel 並列実行するジョブインスタンスの数。 release リリース オブジェクトを生成するようにRunnerに指示します。 resource_group ジョブの並行処理を制限します。 retry ジョブが失敗した場合に、ジョブを自動的に再試行できる条件と回数。 rules ジョブの一部の属性を評価し、そのジョブが作成されるかどうかを決定する条件のリスト。 script Runnerが実行するShellスクリプト。 run Runnerが実行する実行設定。 secrets ジョブに必要なCI/CDシークレット。 services Dockerサービスイメージを使用します。 stage ジョブステージを定義します。 start_in 指定された期間、ジョブの実行を遅らせます。 when: delayed が必要です。 tags Runnerを選択するために使用されるタグのリスト。 timeout プロジェクト全体の設定よりも優先される、カスタムのジョブレベルのタイムアウトを定義します。 trigger ダウンストリームパイプライントリガーを定義します。 variables 個々のジョブのCI/CD変数を定義します。 when ジョブを実行するタイミング。 ジョブキーワード を使用して設定される ジョブ : 現在は使用が推奨されていない 非推奨のキーワード 。 現在は使用が推奨されていない 非推奨のキーワード 。 一部のキーワードはジョブでは定義されません。これらのキーワードは、パイプラインの動作を制御するか、追加のパイプライン設定をインポートします。 一部のキーワードではグローバルデフォルトを設定できます。各デフォルトキーワードは、まだそのキーワードが定義されていないすべてのジョブにコピーされます。 デフォルト設定はジョブの設定とマージされません。ジョブにキーワードがすでに定義されている場合、ジョブキーワードが優先され、そのキーワードのデフォルト設定は使用されません。 キーワードのタイプ : グローバルキーワード。 サポートされている値 : 以下のキーワードにはカスタムデフォルトを設定できます。 image: ruby:3.0 と retry: 2 は、パイプラインのすべてのジョブのデフォルトキーワードです。 rspec ジョブでは image と retry が定義されていないため、デフォルトの image: ruby:3.0 と retry: 2 が使用されます。 rspec 2.7 ジョブでは retry が定義されていませんが、 image が明示的に定義されています。そのため、デフォルトの retry: 2 が使用されますが、デフォルトの image は無視され、ジョブで定義されている image: ruby:2.7 が使用されます。 inherit:default を使用することで、ジョブごとにデフォルトキーワードの継承を制御できます。 グローバルデフォルトは ダウンストリームパイプライン には引き継がれません。ダウンストリームパイプラインは、それをトリガーしたアップストリームパイプラインとは独立して実行されます。 include を使用して、外部のYAMLファイルをCI/CD設定にインクルードすることができます。1つの長い .gitlab-ci.yml ファイルを複数のファイルに分割することで読みやすさを向上させたり、複数の場所で同じ設定が重複する状況を減らしたりすることができます。 テンプレートファイルを中央のリポジトリに保存し、プロジェクトにインクルードすることもできます。 include ファイルは次のように処理されます。 .gitlab-ci.yml ファイルの内容とマージされます。 include キーワードの位置に関係なく、常に最初に評価され、 .gitlab-ci.yml ファイルの内容とマージされます。 すべてのファイルを解決するための制限時間は30秒です。 キーワードのタイプ : グローバルキーワード。 サポートされている値 : include サブキー。 include:component include:project include:template include:integrity include キーワードでは 特定のCI/CD変数 のみを使用できます。 マージを使用して、インクルードされるCI/CD設定をローカルでカスタマイズおよびオーバーライドできます。 インクルードされる設定をオーバーライドするには、 .gitlab-ci.yml ファイルに同じジョブ名またはグローバルキーワードを指定します。2つの設定がマージされ、インクルードされる設定よりも .gitlab-ci.yml ファイル内の設定が優先されます。 再実行する場合: ジョブを再実行すると、 include ファイルは再度フェッチされません。パイプラインのすべてのジョブは、パイプラインの作成時にフェッチされた設定を使用します。そのため、ソース include ファイルが変更されても、ジョブの再実行には影響しません。 パイプラインを再実行すると、 include ファイルが再度フェッチされます。前回のパイプライン実行後にこれらのファイルが変更されていた場合、新しいパイプラインは変更された設定を使用します。 ジョブを再実行すると、 include ファイルは再度フェッチされません。パイプラインのすべてのジョブは、パイプラインの作成時にフェッチされた設定を使用します。そのため、ソース include ファイルが変更されても、ジョブの再実行には影響しません。 パイプラインを再実行すると、 include ファイルが再度フェッチされます。前回のパイプライン実行後にこれらのファイルが変更されていた場合、新しいパイプラインは変更された設定を使用します。 デフォルトでは、 ネストされたインクルード を含めて、パイプラインごとに最大150個のインクルードを使用できます。追加の注意点: GitLab Self-Managedのユーザーは、 maximum includes の値を変更できます。 ネストされたインクルードでは、同じファイルを複数回インクルードできますが、重複したインクルードもカウントの対象になります。 GitLab Self-Managedのユーザーは、 maximum includes の値を変更できます。 ネストされたインクルードでは、同じファイルを複数回インクルードできますが、重複したインクルードもカウントの対象になります。 include:component include:component を使用して、 CI/CDコンポーネント をパイプライン設定に追加します。 キーワードのタイプ : グローバルキーワード。 サポートされている値 : CI/CDコンポーネントの完全なアドレス（形式: <fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version> ）。 include:component の例 : コンポーネントのソースプロジェクトがプライベートな場合、パイプラインを実行するユーザーは少なくともレポーターロールが必要です。内部プロジェクトの場合、認証済みの非外部ユーザーであれば誰でもコンポーネントにアクセスできます。公開プロジェクトの場合、メンバーシップは不要です。 CI/CDコンポーネントを使用する 。 include:local を使用して、 include キーワードを含む設定ファイルと同じリポジトリおよびブランチにあるファイルをインクルードします。シンボリックリンクの代わりに include:local を使用します。 キーワードのタイプ : グローバルキーワード。 ルートディレクトリ（ / ）を基準にしたフルパス: YAMLファイルの拡張子は、 .yml または .yaml である必要があります。 ファイルパスではワイルドカード * と ** を使用 できます。 特定のCI/CD変数 を使用できます。 include:local の例 : 短縮構文を使用してパスを定義することもできます。 .gitlab-ci.yml ファイルとローカルファイルは、同じブランチに存在している必要があります。 Gitサブモジュールパスを使用してローカルファイルをインクルードすることはできません。 include 設定は常に、パイプラインを実行しているプロジェクトではなく、 include キーワードを含むファイルの場所を基準に評価されます。そのため、 ネストされた include が別のプロジェクトの設定ファイル内にある場合、 include: local はその別のプロジェクト内でファイルを確認します。 include:project 同じGitLabインスタンス上の別の非公開プロジェクトからファイルをインクルードするには、 include:project と include:file を使用します。 キーワードのタイプ : グローバルキーワード。 include:project : GitLabプロジェクトのフルパス。 include:file : ルートディレクトリ（ / ）を基準にしたファイルのフルパス、またはファイルパスの配列。YAMLファイルの拡張子は .yml または .yaml でなければなりません。 include:ref : オプション。ファイルの取得元のref。指定しない場合、デフォルトはプロジェクトの HEAD です。 特定のCI/CD変数 を使用できます。 include:project の例 : ref を指定することもできます。 include 設定は常に、パイプラインを実行しているプロジェクトではなく、 include キーワードを含むファイルの場所を基準に評価されます。そのため、 ネストされた include が別のプロジェクトの設定ファイル内にある場合、 include: local はその別のプロジェクト内でファイルを確認します。 パイプラインが開始されると、すべての方法によってインクルードされた .gitlab-ci.yml ファイルの設定が評価されます。この設定はその時点でのスナップショットであり、データベースに保持されます。GitLabは、参照先の .gitlab-ci.yml ファイルの設定が変更されても、次のパイプラインが開始されるまではその変更を反映しません。 include:project のプライベートプロジェクトでは、パイプラインを実行するユーザーは少なくともレポーターロールが必要です。内部プロジェクトの場合、認証済みの非外部ユーザーであれば誰でも含まれているファイルにアクセスできます。公開プロジェクトの場合、メンバーシップは不要です。含まれているプロジェクトに対してユーザーが十分な権限を持っていない場合、 not found or access denied エラーが表示されます。 別のプロジェクトのCI/CD設定ファイルをインクルードする場合は注意してください。CI/CD設定ファイルが変更されても、パイプラインや通知はトリガーされません。セキュリティの観点では、これはサードパーティの依存関係をプルすることと似ています。 ref については以下を検討してください。 特定のSHAハッシュを使用する。これはもっとも安定したオプションです。目的のコミットが確実に参照されるように、40文字の完全なSHAハッシュを使用してください。 ref に短いSHAハッシュを使用すると、あいまいになる可能性があるためです。 他のプロジェクトの ref に対して、 保護ブランチ と 保護タグ の両方のルールを適用する。保護タグと保護ブランチは、変更される前に変更管理を通過する可能性が高くなります。 特定のSHAハッシュを使用する。これはもっとも安定したオプションです。目的のコミットが確実に参照されるように、40文字の完全なSHAハッシュを使用してください。 ref に短いSHAハッシュを使用すると、あいまいになる可能性があるためです。 他のプロジェクトの ref に対して、 保護ブランチ と 保護タグ の両方のルールを適用する。保護タグと保護ブランチは、変更される前に変更管理を通過する可能性が高くなります。 include:remote と完全なURLを使用して、別の場所にあるファイルをインクルードします。 キーワードのタイプ : グローバルキーワード。 HTTP/HTTPS GET リクエストでアクセス可能な公開URL: リモートURLの認証はサポートされていません。 YAMLファイルの拡張子は、 .yml または .yaml である必要があります。 特定のCI/CD変数 を使用できます。 include:remote の例 : すべての ネストされたインクルード は、公開ユーザーとしてコンテキストなしで実行されるため、公開プロジェクトまたはテンプレートのみをインクルードできます。ネストされたインクルードの include セクションでは、変数は使用できません。 別のプロジェクトのCI/CD設定ファイルをインクルードする場合は注意してください。他のプロジェクトのファイルが変更されても、パイプラインや通知はトリガーされません。セキュリティの観点では、これはサードパーティの依存関係をプルすることと似ています。インクルードするファイルの整合性を検証するには、 integrity キーワードを使用することを検討してください。所有している別のGitLabプロジェクトにリンクする場合は、 保護ブランチ と 保護タグ の両方を使用して変更管理ルールを適用することを検討してください。 include:template include:template を使用して、 .gitlab-ci.yml テンプレート をインクルードします。 キーワードのタイプ : グローバルキーワード。 CI/CDテンプレートのファイル名。例: Auto-DevOps.gitlab-ci.yml 。 特定のCI/CD変数 を使用できます。 include:template の例 : 複数の include:template ファイル: すべてのテンプレートは、 lib/gitlab/ci/templates で確認できます。すべてのテンプレートが include:template での使用を前提として設計されているわけではないため、使用する前にテンプレートのコメントを確認してください。 すべての ネストされたインクルード は、公開ユーザーとしてコンテキストなしで実行されるため、公開プロジェクトまたはテンプレートのみをインクルードできます。ネストされたインクルードの include セクションでは、変数は使用できません。 GitLab 17.0で 一般提供 になりました。 インクルードされた設定が spec:inputs を使用しパイプラインに追加される際、 include:inputs を使用して入力パラメータの値を設定します。 キーワードのタイプ : グローバルキーワード。 サポートされている値 : 文字列、数値、またはブール値。 include:inputs の例 : custom_configuration.yml に含まれる設定がパイプラインに追加され、インクルードされる設定の website インプットには My website という値が設定されます。 インクルードされる設定ファイルが spec:inputs:type を使用している場合、入力値は定義された型と一致している必要があります。 インクルードされる設定ファイルが spec:inputs:options を使用している場合、入力値はリストされているオプションのいずれかと一致している必要があります。 include の使用時に入力値を設定する 。 rules と include を組み合わせて使用すると、他の設定ファイルを条件付きでインクルードできます。 キーワードのタイプ : グローバルキーワード。 サポートされている値 : 次の rules サブキー: rules:changes 。 一部の CI/CD変数がサポートされています 。 include:rules の例 : この例では、 INCLUDE_BUILDS 変数の値に応じて次のようになります。 true の場合、 build_jobs.yml の設定がパイプラインにインクルードされます。 true ではない場合、または変数が存在しない場合は、 build_jobs.yml の設定はパイプラインにインクルードされません。 include を使用した例: rules:if 。 rules:changes 。 rules:exists 。 rules:changes 。 include:integrity GitLab 17.9で 導入 されました。 integrity を include:remote と組み合わせて使用して、インクルードされたリモートファイルのSHA256ハッシュを指定します。 integrity の値が実際の内容と一致しない場合、そのリモートファイルは処理されず、パイプラインは失敗します。 キーワードのタイプ : グローバルキーワード。 サポートされている値 : インクルードされるコンテンツのBase64エンコードされたSHA256ハッシュ。 include:integrity の例 : GitLab 18.9で、 ci_cache_remote_includes という 機能フラグ を持つ 実験 として 導入 されました。デフォルトでは無効になっています。 GitLab 19.0で 一般提供 になりました。機能フラグ ci_cache_remote_includes は削除されました。 cache を include:remote と一緒に使用すると、フェッチされたリモートファイルの内容をキャッシュし、HTTPリクエストを削減できます。有効にすると、リモートファイルは指定された有効期間（TTL）の間キャッシュされ、同じリモートインクルードを繰り返し使用する設定でパイプラインのパフォーマンスが向上します。 キャッシュの期間を設定する際には、パフォーマンスと鮮度のトレードオフを考慮してください。キャッシュ期間が長いとパフォーマンスは向上しますが、リモートファイルが頻繁に変更される場合は古いコンテンツが使用される可能性があります。 cache が定義されていない場合、リモートファイルは毎回フェッチされます。 キーワードのタイプ : グローバルキーワード。 true : 1時間のデフォルト有効期間（TTL）でキャッシュを有効にします。 期間（文字列）: 有効なTTL期間文字列は、 minutes 、 hours 、 days などの時間単位を使用します（最小 1 minute ）。 include:cache の例 : キャッシュは include:remote のみで利用可能です。 リモートファイルがキャッシュされると、リモートファイルの内容が変更されても、TTLの有効期限が切れるまでキャッシュされたバージョンが引き続き使用されます。 integrity を cache と一緒に使用すると、キャッシュされたコンテンツを使用している場合でも、パイプラインの実行ごとに整合性チェックが実行されます。 stages を使用して、ジョブのグループを含むステージを定義します。ジョブに stage を指定することで、そのジョブを特定のステージで実行するように設定できます。 .gitlab-ci.yml ファイルで stages が定義されていない場合、デフォルトのパイプラインステージは次のとおりです。 stages に列挙された項目の順序によって、ジョブの実行順序が決まります。 同じステージ内のジョブは並列実行されます。 次のステージのジョブは、前のステージのジョブが正常に完了した後に実行されます。 パイプラインに .pre ステージまたは .post ステージのジョブしか含まれていない場合、そのパイプラインは実行されません。これら以外のステージに少なくとも1つのジョブが必要です。 キーワードのタイプ : グローバルキーワード。 build 内のすべてのジョブは並列実行されます。 build 内のすべてのジョブが成功すると、 test 内のジョブが並列実行されます。 test 内のすべてのジョブが成功すると、 deploy 内のジョブが並列実行されます。 deploy 内のすべてのジョブが成功すると、パイプラインは passed としてマークされます。 いずれかのジョブが失敗すると、パイプラインは failed としてマークされ、後続ステージのジョブは開始されません。現在のステージのジョブは停止されず、引き続き実行されます。 ジョブに stage が指定されていない場合、そのジョブには test ステージが割り当てられます。 ステージが定義されていても、そのステージを使用するジョブが存在しない場合、パイプラインには表示されません。これは、 コンプライアンスパイプライン設定 に役立ちます。 ステージはコンプライアンス設定で定義できますが、使用されなければ非表示のままになります。 定義されたステージをデベロッパーがジョブ定義で使用すると、これらのステージが表示されます。 ステージはコンプライアンス設定で定義できますが、使用されなければ非表示のままになります。 定義されたステージをデベロッパーがジョブ定義で使用すると、これらのステージが表示されます。 ジョブをより早い時点で開始し、ステージの順序を無視するには、 needs キーワードを使用する。 workflow を使用して、パイプラインの動作を制御します。 workflow の設定では、一部の 定義済みCI/CD変数 を使用できますが、ジョブの開始時にのみ定義される変数は使用できません。 workflow: rules の例 ブランチパイプラインとマージリクエストパイプラインを切り替える workflow:auto_cancel:on_new_commit workflow:auto_cancel:on_new_commit を使用して、 冗長なパイプラインを自動キャンセル 機能の動作を設定します。 conservative : パイプラインをキャンセルします。ただし、 interruptible: false が設定されたジョブがまだ開始されていない場合に限ります。定義されていない場合は、この値がデフォルトです。 interruptible : interruptible: true が設定されたジョブのみをキャンセルします。 none : ジョブは自動キャンセルされません。 workflow:auto_cancel:on_new_commit の例 : 新しいコミットがブランチにプッシュされると、GitLabは新しいパイプラインを作成し、 job1 と job2 が開始されます。 ジョブが完了する前に新しいコミットがブランチにプッシュされると、 job1 のみがキャンセルされます。 workflow:auto_cancel:on_job_failure workflow:auto_cancel:on_job_failure を使用して、いずれかのジョブが失敗した場合にキャンセルするジョブを設定します。 all : いずれかのジョブが失敗すると、パイプラインと実行中のすべてのジョブが直ちにキャンセルされます。 none : ジョブは自動キャンセルされません。 workflow:auto_cancel:on_job_failure の例 : この例では、 job2 が失敗した場合、 job1 がまだ実行中であればキャンセルされ、 job3 は開始されません。 ダウンストリームパイプラインから親パイプラインを自動キャンセルする workflow: で name を使用して、パイプラインの名前を定義できます。 定義された名前はすべてのパイプラインに割り当てられます。名前の先頭または末尾のスペースは削除されます。 workflow:name の例 : 定義済み変数を使用した単純なパイプライン名: パイプラインの条件に応じてパイプライン名が異なる設定: 名前が空の文字列の場合、パイプラインには名前が割り当てられません。CI/CD変数のみで構成された名前は、それらの変数もすべて空の場合、空の文字列と評価される可能性があります。 workflow:rules:variables で定義された変数は、すべてのジョブで使用できる デフォルト変数 になります。これには、デフォルトで変数をダウンストリームパイプラインに転送する trigger ジョブも含まれます。ダウンストリームパイプラインが同じ変数を使用する場合、アップストリーム変数の値によって 変数が上書きされます 。そのため、次のいずれかを必ず実施してください。 各プロジェクトのパイプライン設定で一意の変数名を使用する（例: PROJECT1_PIPELINE_NAME ）。 トリガージョブで inherit:variables を使用し、ダウンストリームパイプラインに転送する正確な変数をリストする。 各プロジェクトのパイプライン設定で一意の変数名を使用する（例: PROJECT1_PIPELINE_NAME ）。 トリガージョブで inherit:variables を使用し、ダウンストリームパイプラインに転送する正確な変数をリストする。 workflow における rules キーワードは、 ジョブで定義される rules に似ていますが、パイプライン全体を作成するかどうかを制御します。 trueと評価されるルールがない場合、パイプラインは実行されません。 サポートされている値 : ジョブレベルの rules と同じキーワードの一部を使用できます。 rules: changes 。 rules: exists 。 when 。 workflow とともに使用する場合は always または never のみ指定できます。 workflow:rules の例 : この例では、パイプラインが実行されるのは、コミットタイトル（コミットメッセージの1行目）が -draft で終わっておらず、パイプラインが次のいずれかに該当する場合です。 ルールがブランチパイプライン（デフォルトブランチ以外）とマージリクエストパイプラインの両方に一致する場合、 パイプラインが重複 して作成される可能性があります。 start_in 、 allow_failure 、 needs は、 workflow:rules でサポートされていませんが、構文違反にはなりません。効果はありませんが、将来的に構文エラーを引き起こす可能性があるため、 workflow:rules では使用しないでください。詳細については、 イシュー436473 を参照してください。 workflow:rules の一般的な if 句 。 rules を使用してマージリクエストパイプラインを実行する 。 workflow:rules:variables workflow:rules で variables を使用して、特定のパイプライン条件の変数を定義します。 条件が一致すると変数が作成されます。この変数は、パイプライン内のすべてのジョブで使用できます。すでにその変数がデフォルト変数としてトップレベルで定義されている場合でも、 workflow 変数が優先され、デフォルト変数はオーバーライドされます。 キーワードのタイプ : グローバルキーワード。 サポートされている値 : 変数名と値のペア: 名前には数字、英字、アンダースコア（ _ ）のみを使用できます。 値は文字列でなければなりません。 workflow:rules:variables の例 : ブランチがデフォルトブランチの場合: job1の DEPLOY_VARIABLE は job1-deploy-production です。 job2の DEPLOY_VARIABLE は deploy-production です。 ブランチが feature の場合: job1の DEPLOY_VARIABLE は job1-default-deploy であり、 IS_A_FEATURE は true です。 job2の DEPLOY_VARIABLE は default-deploy であり、 IS_A_FEATURE は true です。 job1の DEPLOY_VARIABLE は job1-default-deploy です。 job2の DEPLOY_VARIABLE は default-deploy です。 workflow:rules:variables で定義された変数は、すべてのジョブで使用できる デフォルト変数 になります。これには、デフォルトで変数をダウンストリームパイプラインに転送する trigger ジョブも含まれます。ダウンストリームパイプラインが同じ変数を使用する場合、アップストリーム変数の値によって 変数が上書きされます 。そのため、次のいずれかを必ず実施してください。 各プロジェクトのパイプライン設定で一意の変数名を使用する（例: PROJECT1_VARIABLE_NAME ）。 トリガージョブで inherit:variables を使用し、ダウンストリームパイプラインに転送する正確な変数をリストする。 各プロジェクトのパイプライン設定で一意の変数名を使用する（例: PROJECT1_VARIABLE_NAME ）。 トリガージョブで inherit:variables を使用し、ダウンストリームパイプラインに転送する正確な変数をリストする。 workflow:rules:auto_cancel workflow:rules:auto_cancel を使用して、 workflow:auto_cancel:on_new_commit 機能または workflow:auto_cancel:on_job_failure 機能の動作を設定します。 on_new_commit : workflow:auto_cancel:on_new_commit on_job_failure : workflow:auto_cancel:on_job_failure workflow:rules:auto_cancel の例 : この例では、デフォルトですべてのジョブの workflow:auto_cancel:on_new_commit が interruptible に設定され、 workflow:auto_cancel:on_job_failure が all に設定されます。ただし、保護ブランチに対してパイプラインが実行される場合、ルールはデフォルトを on_new_commit: none と on_job_failure: none でオーバーライドします。たとえば、パイプラインの実行対象によって、動作は次のように変わります。 保護されていないブランチに対して実行される場合、新しいコミットがプッシュされると、 test-job1 の実行が継続され、 test-job2 はキャンセルされます。 保護ブランチに対して実行される場合、新しいコミットがプッシュされると、 test-job1 と test-job2 の両方の実行が継続されます。 いくつかのキーワードは、YAML設定ファイルのヘッダーセクションで定義する必要があります。ヘッダーはファイルの先頭に配置し、設定の他の部分と --- で区切る必要があります。 YAMLファイルのヘッダーに spec セクションを追加すると、 include キーワードを使用して設定がパイプラインに追加されたときのパイプラインの動作を設定できます。 仕様は設定ファイルの先頭にあるヘッダーセクションで宣言する必要があります。このセクションは、設定の他の部分と --- で区切られています。 spec:inputs を使用して、CI/CD設定に対する インプット を定義できます。 ヘッダーセクションの外部でその値を参照するには、補間形式 $[[ inputs.input-id ]] を使用します。インプットは、パイプライン作成時に設定がフェッチされる際に評価および補間されます。 inputs を使用すると、設定が .gitlab-ci.yml ファイルの内容とマージされる前に補間が完了します。 キーワードのタイプ : ヘッダーキーワード。 spec は、設定ファイルの先頭にあるヘッダーセクションで宣言する必要があります。 サポートされている値 : 予期されるインプットを表す文字列のハッシュ。 spec:inputs の例 : spec:inputs:default を使用してデフォルト値を設定しない限り、インプットは必須です。 include:inputs と組み合わせてインプットを使用する場合を除き、インプットを必須にするのは避けることをおすすめします。 インプットは文字列を想定しています。ただし、 spec:inputs:type を使用して別の型を指定する場合を除きます。 補間ブロックを含む文字列は、1 MB以下にする必要があります。 補間ブロック内の文字列は、1 KB以下にする必要があります。 入力値は 新しいパイプラインの実行時 に定義できます。 spec:inputs で入力パラメータを定義する 。 spec:inputs:default を使用してデフォルト値を設定しない限り、仕様に含まれるインプットはすべて必須になります。 デフォルト値を設定しない場合は default: '' を使用します。 キーワードのタイプ : ヘッダーキーワード。 spec は、設定ファイルの先頭にあるヘッダーセクションで宣言する必要があります。 サポートされている値 : デフォルト値を表す文字列、または '' 。 spec:inputs:default の例 : website は必須であり、定義する必要があります。 user はオプションです。定義されていない場合、値は test-user になります。 flags はオプションです。定義されていない場合、値はありません。 インプットが次の条件に該当する場合、パイプラインは検証エラーで失敗します。 default と options の両方を使用しているが、デフォルト値が、リストされているオプションのいずれでもない。 default と regex の両方を使用しているが、デフォルト値が正規表現と一致しない。 値が type と一致しない。 default と options の両方を使用しているが、デフォルト値が、リストされているオプションのいずれでもない。 default と regex の両方を使用しているが、デフォルト値が正規表現と一致しない。 値が type と一致しない。 description を使用して、特定のインプットに説明を付けます。説明はインプットの動作に影響を与えません。ファイルのユーザーがインプットを理解できるようにする目的でのみ使用されます。 キーワードのタイプ : ヘッダーキーワード。 spec は、設定ファイルの先頭にあるヘッダーセクションで宣言する必要があります。 サポートされている値 : 説明を表す文字列。 spec:inputs:description の例 : 配列型入力のサポートはGitLab 19.0で 導入 されました。 インプットで options を使用して、インプットに許可される値のリストを指定できます。各インプットに指定できるオプションの数は、最大50個までです。 キーワードのタイプ : ヘッダーキーワード。 spec は、設定ファイルの先頭にあるヘッダーセクションで宣言する必要があります。 サポートされている値 : 入力オプションの配列。 spec:inputs:options の例 : environment は必須であり、リスト内のいずれかの値で定義する必要があります。 次の場合、パイプラインは検証エラーで失敗します。 インプットで options と default の両方を使用しているが、デフォルト値が、リストされているオプションのいずれでもない。 いずれかのインプットオプションが type と一致していない。 options を使用する場合は string または number を指定する必要があり、 boolean は使用できない。 インプットで options と default の両方を使用しているが、デフォルト値が、リストされているオプションのいずれでもない。 いずれかのインプットオプションが type と一致していない。 options を使用する場合は string または number を指定する必要があり、 boolean は使用できない。 spec:inputs:regex を使用して、インプットが一致する必要がある正規表現を指定します。 キーワードのタイプ : ヘッダーキーワード。 spec は、設定ファイルの先頭にあるヘッダーセクションで宣言する必要があります。 サポートされている値 : 正規表現である必要があります。 spec:inputs:regex の例 : この例では、 v1.0 または v1.2.3 の入力値は正規表現に一致し、検証に合格します。 v1.A.B の入力値は正規表現と一致せず、検証に失敗します。 inputs:regex は、 type が string の場合にのみ使用できます。 number または boolean の場合は使用できません。 / 文字で正規表現を囲まないでください。たとえば、 /regex.*/ ではなく regex.* を使用します。 inputs:regex は RE2 を使用して正規表現を解析します。 正規表現に対するインプットの検証は、変数の展開前に行われます。インプットテキストに変数の名前が含まれている場合、検証されるのは変数の値ではなく、インプットのraw値（変数名）です。 GitLab 18.7で 導入 されました。 spec:inputs:rules を使用して、他のインプットに基づいて、条件付きの options と default の値を定義します。 キーワードのタイプ : ヘッダーキーワード。 spec は、設定ファイルの先頭にあるヘッダーセクションで宣言する必要があります。 サポートされている値 : ルールオブジェクトの配列。各ルールには以下を含めることができます: if : $[[ inputs.input-id ]] 構文 を使用して、インプット値をチェックする条件式。 options : インプットに対して許可される値の配列。 default : このルールに一致した場合のインプットのデフォルト値。 default: null を使用して、ユーザーが独自の値のインプットを入力できるようにします。 spec:inputs:rules の例 : この例では、 environment が development の場合、ユーザーは small または medium インスタンスのみを選択できます。 environment が production の場合、 large または xlarge インスタンスのみ使用できます。 ルールは順番に評価されます。一致する if 条件を持つ最初のルールが使用されます。 if 条件のないルールは、他のルールが一致しない場合にフォールバックとして機能します。 フォールバックルールは、少なくとも1つの値で options を定義する必要があります。 options を持つすべてのルールは、 options リストに存在する default 値も定義する必要があります。 同じインプットに対して、 rules とトップレベルの options または default の両方を使用することはできません。 spec:inputs:rules を使用して条件付きのインプットオプションを定義する 。 デフォルトでは、インプットは文字列を想定しています。 spec:inputs:type を使用すると、インプットに必要な別の型を指定できます。 キーワードのタイプ : ヘッダーキーワード。 spec は、設定ファイルの先頭にあるヘッダーセクションで宣言する必要があります。 サポートされている値 : 次のいずれかです。 array : インプットの 配列 を受け入れます。 string : 文字列のインプットを受け入れます（定義されていない場合はデフォルト）。 number : 数値のインプットのみを受け入れます。 boolean : true または false のインプットのみを受け入れます。 spec:inputs:type の例 : GitLab 18.6で ci_file_inputs 機能フラグ とともに 導入 されました。デフォルトでは無効になっています。 GitLab 18.9で 一般提供 になりました。機能フラグ ci_file_inputs は削除されました。 spec:include を使用して、他のファイルから外部インプット定義をインクルードします。複数のパイプライン設定でインプット定義を共有して再利用できます。 キーワードのタイプ : ヘッダーキーワード。 spec は、設定ファイルの先頭にあるヘッダーセクションで宣言する必要があります。 サポートされている値 : インクルード場所の配列。 local 、 remote 、および project インクルードのみをサポートします。 spec:include の例 : 異なるソースからの複数のインクルードの場合: CI/CDコンポーネント では spec:include を使用できません。 外部インプットファイルには、 inputs キーのみが含まれている必要があります。他のキーは検証エラーを引き起こします。 最初に外部インプットがマージされ、次にインラインインプットが適用されます。 インライン入力は、含まれている入力と同じ名前にすることはできません。 複数のインプットファイルを含める場合、指定された順序でマージされます。 local 、 remote 、および project インクルードタイプをサポートします。 template 、 component 、または artifact インクルードはサポートされていません。 外部ファイルからのインプットを使用する 。 GitLab 18.6で、 ci_component_context_interpolation という 機能フラグ を持つ ベータ として 導入 されました。デフォルトでは有効になっています。 GitLab 18.7で 一般提供 になりました。機能フラグ ci_component_context_interpolation は削除されました。 spec:component を使用して、 CI/CDコンポーネント で補間に使用できるコンポーネントコンテキストデータを定義します。 コンポーネントコンテキストは、コンポーネント自体のメタデータ（名前、バージョン、コミットSHAなど）を提供します。これにより、コンポーネントテンプレートが独自のメタデータを動的に参照できるようになります。 補間形式 $[[ component.field-name ]] を使用して、コンポーネントテンプレートでコンポーネントコンテキスト値を参照します。 キーワードのタイプ : ヘッダーキーワード。 spec は、設定ファイルの先頭にあるヘッダーセクションで宣言する必要があります。 サポートされている値 : 文字列の配列。各文字列は、次のいずれかである必要があります: name : コンポーネントパスで指定されているコンポーネント名。 sha : コンポーネントのコミットSHA。 version : カタログリソースからの解決済みセマンティックバージョン。次の場合に null を返します: コンポーネントがカタログリソースではない。 参照がブランチ名またはコミットSHA（リリースされたバージョンではない）である。 コンポーネントがカタログリソースではない。 参照がブランチ名またはコミットSHA（リリースされたバージョンではない）である。 reference : コンポーネントパスの @ の後に指定された元の参照。たとえば、 1.0 、 ~latest 、ブランチ名、またはコミットSHA。 spec:component の例 : version フィールドは、以下を使用する場合に実際のセマンティックバージョンに解決されます: @1.0.0 のような完全なバージョン（ 1.0.0 を返します） @1.0 のような部分的なバージョン（たとえば、 1.0.2 のように、一致する最新のバージョンを返します） @~latest （最新のバージョンを返します） @1.0.0 のような完全なバージョン（ 1.0.0 を返します） @1.0 のような部分的なバージョン（たとえば、 1.0.2 のように、一致する最新のバージョンを返します） @~latest （最新のバージョンを返します） reference フィールドは、 @ の後に指定された正確な値を常に返します: @1.0 は 1.0 を返します（ version が 1.0.2 を返す場合があります） @~latest は ~latest を返します（ version は実際のバージョン番号を返します） @abc123 は abc123 を返します（ version が null を返す場合） @1.0 は 1.0 を返します（ version が 1.0.2 を返す場合があります） @~latest は ~latest を返します（ version は実際のバージョン番号を返します） @abc123 は abc123 を返します（ version が null を返す場合） コンポーネントでコンポーネントコンテキストを使用する 。 spec:description GitLab 18.10で 導入 されました。 コンポーネントの短い説明を提供するには、 spec:description を使用します。この説明は、CI/CDカタログのコンポーネント詳細ページで、入力テーブルの上に表示されます。 キーワードのタイプ : ヘッダーキーワード。 spec は、設定ファイルの先頭にあるヘッダーセクションで宣言する必要があります。 サポートされている値 : コンポーネントを説明する文字列。 spec:description の例 : 以降のトピックでは、キーワードを使用してCI/CDパイプラインを設定する方法について説明します。 キャンセルされたジョブに対する after_script コマンドの実行は、GitLab 17.0で 導入 されました。 after_script を使用して、ジョブの before_script セクションと script セクションの完了後に最後に実行するコマンドの配列を定義します。 after_script のコマンドは、次の条件に該当する場合にも実行されます。 before_script セクションまたは script セクションの実行中に、ジョブがキャンセルされた場合。 ジョブで script_failure という種類の失敗が発生した場合（ただし、 それ以外の種類の失敗 では実行されません）。 ジョブの設定とデフォルト設定は一緒にマージされません。パイプラインに default:after_script が定義されていて、ジョブにも after_script がある場合、ジョブの設定が優先され、デフォルト設定は使用されません。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 サポートされている値 : 次の内容を含む配列。 複数行に分割された 長いコマンド。 CI/CD変数が サポートされています 。 after_script の例 : after_script で指定するスクリプトは、 before_script コマンドまたは script コマンドとは別のShellで実行されます。その結果、スクリプトは次のようになります。 現在のワーキングディレクトリがデフォルトにリセットされます（デフォルト値は、 RunnerがGitリクエストをどのように処理するかを定義する変数 に基づいて決まります）。 before_script または script で定義されたコマンドによる変更にはアクセスできません。これには以下が含まれます。 script スクリプトでエクスポートされたコマンドエイリアスと変数。 ワークツリー外の変更（Runnerのexecutorによってアクセス可否が異なります）。たとえば、 before_script または script スクリプトによってインストールされたソフトウェアなどが該当します。 script スクリプトでエクスポートされたコマンドエイリアスと変数。 ワークツリー外の変更（Runnerのexecutorによってアクセス可否が異なります）。たとえば、 before_script または script スクリプトによってインストールされたソフトウェアなどが該当します。 個別のタイムアウトが設定されます。これは5分にデフォルト設定されており、 RUNNER_AFTER_SCRIPT_TIMEOUT 変数で設定できます。 ジョブの終了コードには影響しません。 script セクションが成功し、 after_script がタイムアウトになるか失敗した場合、ジョブはコード 0 （ Job Succeeded ）で終了します。 ジョブがタイムアウトした場合: after_script コマンドはデフォルトでは実行されません。 タイムアウト値を設定 することで、 after_script を確実に実行させることができます。そのためには、ジョブのタイムアウトを超えないように、 RUNNER_SCRIPT_TIMEOUT と RUNNER_AFTER_SCRIPT_TIMEOUT に適切な値を設定します。 after_script コマンドはデフォルトでは実行されません。 タイムアウト値を設定 することで、 after_script を確実に実行させることができます。そのためには、ジョブのタイムアウトを超えないように、 RUNNER_SCRIPT_TIMEOUT と RUNNER_AFTER_SCRIPT_TIMEOUT に適切な値を設定します。 トップレベルで after_script を使用しても、 default セクションでは使用しない場合、 非推奨 になります。 実行のタイミングとファイルインクルード : after_script コマンドは、キャッシュおよびアーティファクトのアップロード操作の前に実行されます。 アーティファクトコレクションを構成した場合: after_script で作成または変更されたファイルは、アーティファクトに含まれます。 after_script で行われた変更は、キャッシュのアップロードに含まれます。 after_script で作成または変更されたファイルは、アーティファクトに含まれます。 after_script で行われた変更は、キャッシュのアップロードに含まれます。 after_script が指定されたキャッシュまたはアーティファクトパスで作成または変更するファイルはすべてキャプチャされ、アップロードされます。このタイミングは、次のようなシナリオに使用できます: メインスクリプトの後にテストレポートまたはカバレッジデータを生成する。 サマリーファイルまたはログを作成する。 ビルド出力をポスト処理する。 メインスクリプトの後にテストレポートまたはカバレッジデータを生成する。 サマリーファイルまたはログを作成する。 次の例では、含まれていないファイルは、アーティファクトまたはキャッシュのアップロードステージの後に作成または変更されたファイルのみです: 詳細については、 ジョブ実行フロー を参照してください。 after_script を default と組み合わせて使用する と、すべてのジョブの後に実行されるコマンドのデフォルト配列を定義できます。 ジョブがキャンセルされた場合に after_script コマンドをスキップ するようにジョブを設定できます。 ゼロ以外の終了コードを無視 できます。 after_script でカラーコードを使用する と、ジョブログのレビューが容易になります。 カスタムの折りたたみ可能なセクションを作成 して、ジョブログ出力をシンプルにできます。 after_script のエラーを無視 できます。 allow_failure を使用して、ジョブが失敗した場合にパイプラインの実行を継続するかどうかを決定します。 パイプラインで後続のジョブを継続して実行させるには、 allow_failure: true を使用します。 パイプラインで後続のジョブの実行を停止させるには、 allow_failure: false を使用します。 ジョブの失敗が許容されている場合（ allow_failure: true ）、オレンジ色の警告（ ）はジョブが失敗したことを示します。ただしパイプラインは成功し、関連するコミットは警告なしで成功としてマークされます。 このような警告は、次の場合に表示されます。 ステージ内の他のすべてのジョブが成功した場合。 パイプライン内の他のすべてのジョブが成功した場合。 allow_failure のデフォルト値は次のとおりです。 rules 内で when: manual を使用しているジョブ: false 。 その他すべてのケース: false 。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 true または false 。 allow_failure の例 : この例では、 job1 と job2 は並列実行されます。 job1 が失敗した場合、 deploy ステージのジョブは開始されません。 job2 が失敗した場合、 deploy ステージのジョブは開始できます。 allow_failure を rules のサブキーとして使用できます。 allow_failure: true が設定されている場合、そのジョブは常に成功と見なされます。そのため、そのジョブが失敗しても、 when: on_failure が設定された後続のジョブは開始されません。 手動ジョブに allow_failure: false を設定することで、 ブロック手動ジョブ を作成できます。ブロックされたパイプラインは、その手動ジョブが開始されて正常に完了するまで、後続ステージのジョブを実行しません。 allow_failure:exit_codes allow_failure:exit_codes を使用して、ジョブの失敗を許容する条件を制御します。ジョブは、リストされた終了コードのいずれかの場合は allow_failure: true 、それ以外の終了コードに対しては allow_failure がfalseとなります。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 allow_failure の例 : GitLab Runner 18.1で 更新 されました。キャッシュ処理中に symlinks が追跡されることはなくなりました。これは、旧バージョンのGitLab Runnerにおいて一部のエッジケースで発生していました。 artifacts を使用して、 ジョブアーティファクト として保存するファイルを指定します。ジョブアーティファクトは、ジョブが 成功した場合、失敗した場合、または常に、 ジョブに添付されるファイルとディレクトリのリストです。 アーティファクトは、ジョブの完了後にGitLabに送信されます。サイズが 最大アーティファクトサイズ よりも小さい場合、GitLab UIでダウンロードできます。 デフォルトでは、後続ステージのジョブは、前のステージのジョブによって作成されたすべてのアーティファクトを自動的にダウンロードします。 dependencies を使用すると、ジョブにおけるアーティファクトのダウンロード動作を制御できます。 needs キーワードを使用している場合、ジョブは needs 設定で定義されたジョブからのみアーティファクトをダウンロードできます。 デフォルトでは、成功したジョブのジョブアーティファクトのみが収集されます。 キャッシュ が復元された後に、アーティファクトが復元されます。 ジョブの設定とデフォルト設定は一緒にマージされません。パイプラインに default:artifacts が定義されていて、ジョブにも artifacts がある場合、ジョブの設定が優先され、デフォルト設定は使用されません。 アーティファクトの詳細についてはこちらを参照してください 。 artifacts:paths パスはプロジェクトディレクトリ（ $CI_PROJECT_DIR ）を基準にした相対パスであり、プロジェクトディレクトリの外部に直接リンクすることはできません。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 プロジェクトディレクトリを基準にしたファイルパスの配列。 glob パターンおよび doublestar.Glob パターンを使用するワイルドカードを使用できます。 GitLab Pagesジョブ の場合: GitLab 17.10以降 では、 pages.publish パスは自動的に artifacts:paths に付加されるため、再度指定する必要はありません。 GitLab 17.10以降 では、 pages.publish パスが指定されていない場合、 public ディレクトリが自動的に artifacts:paths に付加されます。 GitLab 17.10以降 では、 pages.publish パスは自動的に artifacts:paths に付加されるため、再度指定する必要はありません。 GitLab 17.10以降 では、 pages.publish パスが指定されていない場合、 public ディレクトリが自動的に artifacts:paths に付加されます。 CI/CD変数が サポートされています 。 artifacts:paths の例 : この例では、 .config と、 binaries ディレクトリ内にあるすべてのファイルを含むアーティファクトを作成します。 artifacts:name と組み合わせて使用しない場合、アーティファクトファイルの名前は artifacts になり、ダウンロード時に artifacts.zip になります。 特定のジョブがどのジョブからアーティファクトをフェッチするかを制限するには、 dependencies を参照してください。 ジョブアーティファクトを作成する 。 artifacts:exclude artifacts:exclude を使用して、ファイルがアーティファクトアーカイブに追加されないようにします。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 プロジェクトディレクトリを基準にしたファイルパスの配列。 glob パターンまたは doublestar.PathMatch パターンを使用するワイルドカードを使用できます。 artifacts:exclude の例 : この例では、 binaries/ 内のすべてのファイルが保存されますが、 binaries/ 以下のサブディレクトリにある *.o ファイルは保存されません。 artifacts:exclude で指定されたパスは再帰的には検索されません。 artifacts:untracked で一致したファイルも artifacts:exclude を使用して除外できます。 ジョブアーティファクトからファイルを除外する 。 artifacts:expire_in expire_in を使用して、 ジョブアーティファクト が期限切れになり削除されるまでに保存される期間を指定します。 expire_in の設定は、以下には影響しません。 最新ジョブのアーティファクト（ただし、 プロジェクトレベル または インスタンス全体 で最新ジョブのアーティファクトの保持が無効になっている場合を除く）。 期限が切れたアーティファクトは、デフォルトでは毎時（cronジョブを使用して）削除され、アクセスできなくなります。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 サポートされている値 : 有効期間。単位が指定されていない場合は秒単位です。有効な値の例は以下のとおりです。 47 yrs 6 mos and 4d 3 weeks and 2 days artifacts:expire_in の例 : 有効期間は、アーティファクトがGitLabにアップロードされて保存された時点から始まります。有効期間が定義されていない場合は、 インスタンス全体の設定 がデフォルトで使用されます。 有効期間をオーバーライドし、アーティファクトが自動的に削除されないように保護するには、次のようにします。 ジョブページで 維持 を選択します。 expire_in の値を never に設定します。 ジョブページで 維持 を選択します。 expire_in の値を never に設定します。 有効期間が短すぎると、長いパイプラインの後半のステージにあるジョブが、前半のジョブから期限切れのアーティファクトをフェッチしようとする可能性があります。アーティファクトが期限切れになっている場合、それらをフェッチしようとしたジョブは could not retrieve the needed artifacts エラー で失敗します。有効期間を長く設定するか、後続のジョブで dependencies を使用して、期限切れのアーティファクトをフェッチしないようにしてください。 artifacts:expire_in は、GitLab Pagesのデプロイには影響しません。Pagesのデプロイの有効期間を設定するには、 pages.expire_in を使用します。 artifacts:expose_as artifacts:expose_as キーワードを使用して、 マージリクエストUIでアーティファクトを公開します 。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 マージリクエストUIに表示する、アーティファクトのダウンロードリンクの名前。 artifacts:paths と組み合わせて使用する必要があります。 artifacts:expose_as の例 : マージリクエストごとに最大10個のジョブで、 expose_as をジョブごとに1回だけ使用できます。 Globパターンはサポートされていません。 アーティファクトは常にGitLabに送信されます。 artifacts:paths 値がない限り、UIに表示されます: CI/CD変数 を使用している。 ディレクトリを定義しているが、パスの末尾が / ではない。たとえば、 artifacts:expose_as で directory/ は機能しますが、 directory は機能しません。 CI/CD変数 を使用している。 ディレクトリを定義しているが、パスの末尾が / ではない。たとえば、 artifacts:expose_as で directory/ は機能しますが、 directory は機能しません。 artifacts:paths に単一のファイルのみが含まれている場合、リンクはそのファイルを直接開きます。それ以外の場合はすべて、リンクは アーティファクトブラウザー を開きます。 リンクされたファイルはデフォルトでダウンロードされます。 GitLab Pages が有効になっている場合は、ブラウザで一部のアーティファクトのファイル拡張子を直接プレビューできます。詳細については、 アーティファクトアーカイブのコンテンツを参照する を参照してください。 マージリクエストUIでジョブアーティファクトを公開する 。 artifacts:name キーワードを使用して、作成されたアーティファクトアーカイブの名前を定義します。アーカイブごとに一意の名前を指定できます。 定義されていない場合、デフォルトの名前は artifacts であり、ダウンロード時に artifacts.zip になります。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 アーティファクトアーカイブの名前。CI/CD変数が サポートされています 。 artifacts:paths と組み合わせて使用する必要があります。 artifacts:name の例 : 現在のジョブの名前でアーカイブを作成するには: CI/CD変数を使用してアーティファクト設定を定義する artifacts:public artifacts:public は、より多くのオプションを持つ artifacts:access に置き換えられました。 artifacts:public を使用して、パブリックパイプライン内のジョブアーティファクトが匿名ユーザー、またはゲストロールとレポーターロールによってGitLab UIおよびAPIでダウンロードできるかどうかを制御します。 このオプションは、GitLab UIとAPIのアクセスのみに影響します。ジョブトークンを使用するCI/CDジョブは、この設定に関係なく、Runner APIでアーティファクトにアクセスできます。ジョブトークンアクセスを制限するには、プロジェクトの CI/CD表示レベル設定 を プロジェクトメンバーのみ に構成します。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 true （デフォルト）: パブリックパイプラインのジョブのアーティファクトは、匿名ユーザー、またはゲストロールとレポーターロールなど、誰でもダウンロードできます。 false : ジョブ内のアーティファクトは、デベロッパー、メンテナー、またはオーナーロールを持つユーザーのみがダウンロードできます。 artifacts:public の例 : artifacts:access maintainer オプションはGitLab 18.4で 導入 されました。 artifacts:access を使用して、GitLab UIまたはAPIからジョブアーティファクトにアクセスできるユーザーを決定します。このオプションを使用しても、アーティファクトをダウンストリームパイプラインに転送できなくなることはありません。 同じジョブ内で artifacts:public と artifacts:access を併用することはできません。 このオプションは、GitLab UIとAPIのアクセスのみに影響します。ジョブトークンを使用するCI/CDジョブは、この設定に関係なく、Runner APIでアーティファクトにアクセスできます。ジョブトークンアクセスを制限するには、プロジェクトの CI/CD表示レベル設定 を プロジェクトメンバーのみ に構成します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 all （デフォルト）: 公開パイプラインのジョブのアーティファクトは、匿名ユーザー、ゲストユーザー、レポーターユーザーなど誰でもダウンロードできます。 developer : ジョブ内のアーティファクトは、デベロッパー、メンテナー、またはオーナーロールを持つユーザーのみがダウンロードできます。 maintainer : ジョブ内のアーティファクトは、メンテナーまたはオーナーロールを持つユーザーのみがダウンロードできます。 none : 誰もジョブのアーティファクトをダウンロードできません。 artifacts:access の例 : artifacts:access はすべての artifacts:reports にも影響するため、 レポートのアーティファクト へのアクセスを制限することもできます。 artifacts:reports artifacts:reports を使用して、ジョブにインクルードされたテンプレートによって生成されたアーティファクトを収集します。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 利用可能な アーティファクトレポートのタイプ のリストを参照してください。 artifacts:reports の例 : 子パイプラインからのアーティファクト を使用して、親パイプラインでレポートを組み合わせる操作はサポートされていません。詳細については、 エピック8205 を参照してください。 レポートの出力ファイルを参照してダウンロードできるようにするには、 artifacts:paths キーワードを含めます。これにより、アーティファクトのアップロードと保存が2回実行されます。 artifacts: reports のために作成されたアーティファクトは、ジョブの結果（成功または失敗）にかかわらず、常にアップロードされます。 artifacts:expire_in を使用して、アーティファクトの有効期限を設定できます。 artifacts:untracked artifacts:untracked を使用して、（ artifacts:paths で定義されたパスとともに）すべての追跡していないGitファイルをアーティファクトとして追加します。 artifacts:untracked はリポジトリの .gitignore の設定を無視するため、 .gitignore 内の一致するアーティファクトがインクルードされます。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 true または false （定義されていない場合はデフォルト）。 artifacts:untracked の例 : 追跡していないGitファイルをすべて保存します。 追跡していないファイルをアーティファクトに追加する 。 artifacts:when を使用して、ジョブの失敗時、または失敗にかかわらずアーティファクトをアップロードします。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 on_success （デフォルト）: ジョブが成功した場合にのみアーティファクトをアップロードします。 on_failure : ジョブが失敗した場合にのみアーティファクトをアップロードします。 always : 常にアーティファクトをアップロードします（ジョブがタイムアウトになった場合を除く）。たとえば、失敗したテストの問題解決に必要な アーティファクトをアップロードする 場合などです。 artifacts:when の例 : artifacts:reports で作成されたアーティファクトは、ジョブの結果（成功または失敗）に関係なく常にアップロードされます。 artifacts:when はこの動作を変更しません。 before_script を使用して、 アーティファクト が復元された後、各ジョブの script コマンドの前に実行するコマンドの配列を定義します。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 サポートされている値 : 次の内容を含む配列。 複数行に分割された 長いコマンド。 CI/CD変数が サポートされています 。 before_script の例 : before_script で指定したスクリプトが、メインの script で指定したスクリプトと連結されます。連結されたスクリプトは、1つのShellでまとめて実行されます。 before_script を default セクションではなくトップレベルで使用することは、 非推奨です 。 before_script を default と組み合わせて使用 すると、すべてのジョブで script コマンドの前に実行されるコマンドのデフォルトの配列を定義できます。 ジョブの設定とデフォルト設定は一緒にマージされません。パイプラインに default:before_script が定義されていて、ジョブにも before_script がある場合、ジョブの設定が優先され、デフォルト設定は使用されません。 ジョブの設定とデフォルト設定は一緒にマージされません。パイプラインに default:before_script が定義されていて、ジョブにも before_script がある場合、ジョブの設定が優先され、デフォルト設定は使用されません。 ゼロ以外の終了コードを無視 できます。 before_script でカラーコードを使用する と、ジョブログのレビューが容易になります。 カスタムの折りたたみ可能なセクションを作成 して、ジョブログ出力をシンプルにできます。 GitLab Runner 18.1で 更新 されました。キャッシュ処理中に symlinks が追跡されることはなくなりました。これは、旧バージョンのGitLab Runnerにおいて一部のエッジケースで発生していました。 cache を使用して、ジョブ間でキャッシュするファイルとディレクトリのリストを指定します。ローカルの実行コピーにあるパスのみを使用できます。 キャッシュは次のようになります。 パイプラインとジョブ間で共有されます。 デフォルトでは、 保護 ブランチと保護されていないブランチの間では共有されません。 アーティファクト の前に復元されます。 最大4つの キャッシュ に制限されています。 特定のジョブのキャッシュを無効にできます 。たとえば、以下をオーバーライドする場合です。 default で定義されたデフォルトのキャッシュ。 include で追加されたジョブの設定。 ジョブの設定とデフォルト設定は一緒にマージされません。パイプラインに default:cache が定義されていて、ジョブにも cache がある場合、ジョブの設定が優先され、デフォルト設定は使用されません。 キャッシュの詳細については、 GitLab CI/CDでのキャッシュ を参照してください。 トップレベルで cache を使用しても、 default セクションでは使用しない場合、 非推奨 になります。 cache:paths キーワードを使用して、キャッシュするファイルまたはディレクトリを選択します。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 プロジェクトディレクトリ（ $CI_PROJECT_DIR ）を基準にしたパスの配列。 glob パターンおよび doublestar.Glob パターンを使用するワイルドカードを使用できます。 CI/CD変数 がサポートされています。 cache:paths の例 : binaries にある .apk で終わるすべてのファイルと、 .config ファイルをキャッシュします。 cache:paths キーワードでは、追跡していないファイルや .gitignore ファイルに記載されているファイルもキャッシュの対象になります。 詳細な cache:paths の例については、 CI/CDキャッシュの例 を参照してください。 cache:key キーワードを使用して、各キャッシュに一意の識別キーを指定します。同じキャッシュキーを使用するすべてのジョブは、異なるパイプラインでも同じキャッシュを使用します。 設定されていない場合のデフォルトのキーは default です。 cache キーワードを指定していても cache:key を指定していないジョブはすべて、 default キャッシュを共有します。 cache: paths と組み合わせて使用する必要があります。そうしないと、何もキャッシュされません。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 Windowsバッチ を使用してShellスクリプトを実行する場合は、 $ を % に置き換える必要があります。例: key: %CI_COMMIT_REF_SLUG% cache:key の値に次の文字を含めることはできません。 / 、またはそのURIエンコード形式である %2F 。 . のみ（任意の数）、またはそのURIエンコード形式である %2E 。 / 、またはそのURIエンコード形式である %2F 。 . のみ（任意の数）、またはそのURIエンコード形式である %2E 。 キャッシュはジョブ間で共有されるため、ジョブごとに異なるパスを使用している場合は、それぞれ異なる cache:key も設定する必要があります。そうしないと、キャッシュの内容が上書きされる可能性があります。 指定された cache:key が見つからない場合に使用する フォールバックキャッシュキー を指定できます。 1つのジョブで 複数のキャッシュキーを使用 できます。 詳細な cache:key の例については、 CI/CDキャッシュの例 を参照してください。 指定されたファイルの内容が変更されたときに、 cache:key:files を使用して新しいキャッシュキーを生成します。コンテンツが変更されない場合、キャッシュキーはブランチおよびパイプライン全体で一貫性を保ちます。キャッシュを再利用して再構築する頻度を減らすことができるため、後続のパイプラインの実行が高速化されます。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 最大2つのファイルパスまたはパターンの配列。 CI/CD変数はサポートされていません。 cache:key:files の例 : この例では、RubyとNode.jsの依存関係のキャッシュを作成します。キャッシュは、 Gemfile.lock ファイルと package.json ファイルの現行バージョンに関連付けられています。これらのファイルのいずれかが変更されると、新しいキャッシュキーが計算され、新しいキャッシュが作成されます。後続のジョブの実行で cache:key:files が使用され、同じ Gemfile.lock および package.json を参照している場合には、依存関係を再構築せずに新しいキャッシュが使用されます。 キャッシュ key は、リストされたファイルの内容から計算されたSHAです。ファイルが存在しない場合、キーの計算では無視されます。指定されたファイルが存在しない場合、フォールバックキーは default です。 **/package.json などのワイルドカードパターンを使用できます。 最大2つのファイルを指定できます。許可されるパスまたはパターンの数を増やすための更新については、 イシュー301161 を参照してください。 指定されたファイルの最新のコミットが変更されたときに、 cache:key:files_commits を使用して新しいキャッシュキーを生成します。 cache:key:files_commits キャッシュキーは、ファイルの内容が同一のままであっても、指定されたファイルに新しいコミットがある場合は常に変更されます。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 最大2つのファイルパスまたはパターンの配列。 cache:key:files_commits の例 : この例では、 package.json と yarn.lock のコミット履歴に基づいてキャッシュを作成します。これらのファイルのコミット履歴が変更された場合、新しいキャッシュキーが計算され、新しいキャッシュが作成されます。 キャッシュ key は、指定されたファイルごとに最新のコミットから計算されたSHAです。 ファイルが存在しない場合、キーの計算では無視されます。 指定されたファイルが存在しない場合、フォールバックキーは default です。 同じキャッシュ構成で cache:key:files と一緒に使用することはできません。 cache:key:prefix を使用して、 cache:key:files で計算されたSHAとプレフィックスを組み合わせます。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 cache:key:prefix の例 : たとえば $CI_JOB_NAME という prefix を追加すると、キーは rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5 のようになります。ブランチで Gemfile.lock が変更されると、そのブランチには cache:key:files に対する新しいSHAチェックサムが設定されます。これにより、新しいキャッシュキーが生成され、そのキーに対する新しいキャッシュが作成されます。 Gemfile.lock が見つからない場合、 default にプレフィックスが追加されます。この例では、キーは rspec-default になります。 cache:key:files に指定されたファイルがコミットで変更されていない場合は、 default キーにプレフィックスが追加されます。 cache:untracked untracked: true を使用して、Gitリポジトリで追跡していないすべてのファイルをキャッシュします。追跡していないファイルには、次のファイルが含まれます。 .gitignore 設定 が原因で無視されているファイル。 作成されたが、 git add でステージングされていないファイル。 追跡していないファイルをキャッシュすると、ジョブが次のようなものをダウンロードした際に、予期せず大きなキャッシュが作成される可能性があります。 通常は追跡されない依存関係（gemやノードモジュールなど）。 別のジョブからの アーティファクト 。デフォルトでは、アーティファクトから抽出されたファイルは追跡されません。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 true または false （デフォルト）。 cache:untracked の例 : cache:untracked と cache:paths を組み合わせて指定すると、追跡していないすべてのファイルと、設定されたパス内のファイルをキャッシュできます。 cache:paths は、追跡したファイルや作業ディレクトリの外部にあるファイルを含む、特定のファイルをキャッシュするために使用します。 cache: untracked を使用することで、追跡していないファイルもすべてキャッシュすることができます。例: rspec : script : test cache : untracked : true paths : - binaries/ この例では、ジョブはリポジトリ内の追跡していないすべてのファイルと、 binaries/ 内のすべてのファイルをキャッシュします。 binaries/ 内に追跡していないファイルがある場合、それらはこの両方のキーワードでカバーされます。 cache:untracked と cache:paths を組み合わせて指定すると、追跡していないすべてのファイルと、設定されたパス内のファイルをキャッシュできます。 cache:paths は、追跡したファイルや作業ディレクトリの外部にあるファイルを含む、特定のファイルをキャッシュするために使用します。 cache: untracked を使用することで、追跡していないファイルもすべてキャッシュすることができます。例: この例では、ジョブはリポジトリ内の追跡していないすべてのファイルと、 binaries/ 内のすべてのファイルをキャッシュします。 binaries/ 内に追跡していないファイルがある場合、それらはこの両方のキーワードでカバーされます。 cache:unprotect cache:unprotect を使用して、 保護 ブランチと保護されていないブランチの間でキャッシュが共有されるように設定します。 true に設定すると、保護ブランチへのアクセス権を持たないユーザーでも、保護ブランチで使用されるキャッシュキーを読み書きできるようになります。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 true または false （デフォルト）。 cache:unprotect の例 : cache:when を使用して、ジョブのステータスに基づいてキャッシュを保存するタイミングを定義します。 cache: paths と組み合わせて使用する必要があります。そうしないと、何もキャッシュされません。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 on_success （デフォルト）: ジョブが成功した場合にのみキャッシュを保存します。 on_failure : ジョブが失敗した場合にのみキャッシュを保存します。 always : キャッシュを常に保存します。 cache:when の例 : この例では、ジョブの成功または失敗にかかわらずキャッシュを保存します。 キャッシュのアップロードとダウンロードの動作を変更するには、 cache:policy キーワードを使用します。デフォルトでは、ジョブはジョブの開始時にキャッシュをダウンロードし、ジョブの終了時に変更をキャッシュにアップロードします。このキャッシュスタイルは pull-push ポリシー（デフォルト）です。 ジョブの開始時にキャッシュをダウンロードするだけで、ジョブの終了時に変更をアップロードしないようにジョブを設定するには、 cache:policy:pull を使用します。 ジョブの終了時にキャッシュをアップロードするだけで、ジョブの開始時にキャッシュをダウンロードしないようにジョブを設定するには、 cache:policy:push を使用します。 同じキャッシュを使用する多数のジョブが並列実行される場合は、 pull ポリシーを使用します。このポリシーにより、ジョブの実行が高速化され、キャッシュサーバーの負荷も軽減されます。キャッシュを構築するために、 push ポリシーを指定したジョブを使用できます。 cache: paths と組み合わせて使用する必要があります。そうしないと、何もキャッシュされません。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 pull-push （デフォルト） cache:policy の例 : 変数を使用して、ジョブのキャッシュポリシーを制御 できます。 cache:fallback_keys cache:fallback_keys を使用して、 cache:key に対応するキャッシュが見つからない場合に、キャッシュの復元を試行するキーのリストを指定します。キャッシュは、 fallback_keys セクションで指定された順序で取得されます。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 cache:fallback_keys の例 : coverage とカスタム正規表現を使用して、ジョブの出力からコードカバレッジを抽出する方法を設定します。GitLabは、一致したパーセンテージをMRウィジェット、パイプラインジョブリスト、および分析グラフに表示します。 RE2正規表現。冒頭と末尾の両方が / である必要があります。カバレッジの数値と一致する必要があります。周囲のテキストも含めて一致しても問題ありません。そのため、正確な数値をキャプチャするために正規表現の文字グループを使用する必要はありません。RE2構文を使用するため、すべてグループは非キャプチャグループでなければなりません。 GitLabが、ジョブログに対して正規表現が一致するかどうかをチェックします。 Code coverage: 67.89% of lines covered のような行が一致します。 GitLabは、一致したフラグメントを \d+(?:\.\d+)? と照合して数値を抽出します。サンプルの正規表現は 67.89 と一致します。 ジョブの出力に一致する行が複数ある場合、最後の行が使用されます。 1行に複数のマッチがある場合、最後のマッチが使用されます。 一致するフラグメントに複数のカバレッジ番号がある場合、最初の番号が使用されます。 子パイプライン からのカバレッジ出力は記録されません。 イシュー280818 を参照してください。 MR差分でコード行ごとの差分アノテーションを表示するには、 artifacts:reports:coverage_report を別途設定します。いずれか一方を設定しても、もう一方は有効になりません。 dast_configuration 提供形態 : GitLab.com、GitLab Self-Managed、GitLab Dedicated dast_configuration キーワードを使用して、CI/CD設定で使用するサイトプロファイルとスキャナープロファイルを指定します。両方のプロファイルが、あらかじめプロジェクトで作成されている必要があります。ジョブのステージは dast である必要があります。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : site_profile と scanner_profile （それぞれ1つずつ）。 ジョブで使用するサイトプロファイルを指定するには、 site_profile を使用します。 ジョブで使用するスキャナープロファイルを指定するには、 scanner_profile を使用します。 dast_configuration の例 : この例では、 dast ジョブが、 include キーワードで追加された dast 設定を拡張し、特定のサイトプロファイルおよびスキャナープロファイルを選択しています。 サイトプロファイルまたはスキャナープロファイルに含まれる設定は、DASTテンプレートに含まれる設定よりも優先されます。 dependencies キーワードを使用して、 アーティファクト のフェッチ元のジョブのリストを定義します。指定されたジョブはすべて、先行するステージに存在する必要があります。アーティファクトをまったくダウンロードしないようにジョブを設定することもできます。 ジョブで dependencies が定義されていない場合、前のステージにあるすべてのジョブが依存対象と見なされ、ジョブはそれらのジョブからすべてのアーティファクトをフェッチします。 同じステージ内のジョブからアーティファクトをフェッチするには、 needs:artifacts を使用する必要があります。同じジョブの中で dependencies を needs と組み合わせて使用しないでください。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 アーティファクトのフェッチ元のジョブの名前。 空の配列（ [] ）。アーティファクトをダウンロードしないようにジョブを設定します。 dependencies の例 : この例では、 build mac と build linux の2つのジョブがアーティファクトを生成します。 test mac が実行されると、 build mac からのアーティファクトがダウンロードされ、ビルドのコンテキストで抽出されます。 test linux も同様に、 build linux からのアーティファクトを取得します。 deploy ジョブは、 ステージ の優先順位に従って、それ以前のすべてのジョブからアーティファクトをダウンロードします。 以前のジョブがアーティファクトを生成しない場合、または実行されなかった手動ジョブである場合でも、依存するジョブは実行され、エラーは発生しません。 依存先のジョブのアーティファクトが 期限切れ であるか 削除 されている場合、ジョブは失敗します。 environment を使用して、ジョブがデプロイされる 環境 を定義します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : ジョブのデプロイ先の環境の名前。次のいずれかの形式で指定します。 平文（英字、数字、スペース、および文字 - 、 _ 、 / 、 $ 、 { 、 } を含む）。 CI/CD変数（定義済みの変数、プロジェクト、グループ、インスタンスの変数、または .gitlab-ci.yml ファイルで定義された変数を含む）。 script セクションで定義された変数は使用できません。 environment の例 : environment を指定しても、その名前の環境が存在しない場合は、環境が作成されます。 environment:name 一般的な環境名は qa 、 staging 、 production ですが、任意の名前を使用できます。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : ジョブのデプロイ先の環境の名前。次のいずれかの形式で指定します。 平文（英字、数字、スペース、および文字 - 、 _ 、 / 、 $ 、 { 、 } を含む）。 CI/CD変数 （定義済みの変数、プロジェクト、グループ、インスタンスの変数、または .gitlab-ci.yml ファイルで定義された変数を含む）。 script セクションで定義された変数は使用できません。 environment:name の例 : environment:url キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 単一のURL。次のいずれかの形式で指定します。 平文（例: https://prod.example.com ）。 CI/CD変数 （定義済みの変数、プロジェクト、グループ、インスタンスの変数、または .gitlab-ci.yml ファイルで定義された変数を含む）。 script セクションで定義された変数は使用できません。 environment:url の例 : ジョブが完了したら、URLにアクセスできます。URLにアクセスするには、マージリクエスト、環境、またはデプロイページでボタンを選択します。 environment:on_stop environment で定義されている on_stop キーワードを使用して、環境を閉じる（停止する）ことができます。これは、環境を閉じるために実行される別のジョブを宣言します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 詳細と例については、 environment:action を参照してください。 environment:action action キーワードを使用して、ジョブが環境をどのように操作するかを指定します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 次のキーワードのいずれか。 environment:action の例 : environment:auto_stop_in GitLab 17.7で prepare 、 access 、および verify 環境アクションをサポートするために 更新 されました。 auto_stop_in キーワードは、環境のライフタイムを指定します。環境の有効期限が切れると、GitLabは自動的にその環境を停止します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 自然言語で記述された期間。たとえば、以下の表記はすべて同等です。 CI/CD変数が サポートされています 。 environment:auto_stop_in の例 : review_app の環境が作成されると、その環境のライフタイムは 1 day に設定されます。レビューアプリがデプロイされるたびに、そのライフタイムも 1 day にリセットされます。 auto_stop_in キーワードは、 stop を除くすべての 環境アクション に使用できます。一部のアクションは、環境のスケジュールされた停止時間をリセットするために使用できます。詳細については、 準備または検証目的で環境にアクセスする を参照してください。 環境の自動停止に関するドキュメント 。 environment:kubernetes agent キーワードは、GitLab 17.6で 導入 されました。 namespace および flux_resource_path キーワードは、GitLab 17.7で 導入 されました。 namespace および flux_resource_path キーワードは、GitLab 18.4で 非推奨 になりました。 dashboard:namespace および dashboard:flux_resource_path キーワードは、GitLab 18.4で 導入 されました。 kubernetes キーワードを使用して、環境の Kubernetes向けダッシュボード と GitLab管理のKubernetesリソース を構成します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 agent : Kubernetes向けGitLabエージェント を指定する文字列。形式は path/to/agent/project:agent-name です。エージェントがパイプラインを実行しているプロジェクトに接続されている場合は、 $CI_PROJECT_PATH:agent-name を使用します。 dashboard:namespace : 環境がデプロイされるKubernetesネームスペースを表す文字列。ネームスペースは、 agent キーワードと一緒に設定する必要があります。 namespace は 非推奨 です。 dashboard:flux_resource_path : HelmRelease など、Fluxリソースへのフルパスを表す文字列。Fluxリソースは、 agent および dashboard:namespace キーワードとともに設定する必要があります。 flux_resource_path は 非推奨 です。 managed_resources : 環境の GitLab管理のKubernetesリソース を構成するための enabled キーワードを使用したハッシュ。 managed_resources:enabled : GitLab管理のKubernetesリソースが環境で有効になっているかどうかを示すブール値。 managed_resources:enabled : GitLab管理のKubernetesリソースが環境で有効になっているかどうかを示すブール値。 dashboard : 環境の Kubernetes向けダッシュボード を構成するための dashboard:namespace および dashboard:flux_resource_path キーワードを使用したハッシュ。 environment:kubernetes の例 : 管理対象リソースを無効にする場合の environment:kubernetes の例 : deploy ジョブを設定して production 環境にデプロイします。 agent-name という名前の エージェント を環境に関連付けます。 ネームスペースが my-namespace に設定され、 flux_resource_path に helm.toolkit.fluxcd.io/v2/namespaces/flux-system/helmreleases/helm-release-resource が指定された環境向けに、 Kubernetesのダッシュボード を設定します。 ダッシュボードを使用するには、 Kubernetes向けGitLabエージェントをインストール し、環境のプロジェクトまたはその親グループの user_access を設定する 必要があります。 ジョブを実行するユーザーには、クラスターエージェントへのアクセス権限が必要です。権限がない場合、ダッシュボードは agent 、 namespace 、 flux_resource_path 属性を無視します。 agent のみを設定する場合は、 namespace を設定する必要はなく、 flux_resource_path を設定することはできません。ただし、この設定では、Kubernetesのダッシュボードにクラスター内のすべてのネームスペースが一覧表示されます。 environment:deployment_tier CI/CD変数のサポートは、GitLab 18.5で 追加 されました。 deployment_tier キーワードを使用して、デプロイ環境のプランを指定します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 次のいずれか。 CI/CD変数 （定義済みの変数、プロジェクト、グループ、インスタンスの変数、または .gitlab-ci.yml ファイルで定義された変数を含む）。 script セクションで定義された変数は使用できません。 environment:deployment_tier の例 : このジョブ定義から作成された環境には、この値に基づいて プラン が割り当てられます。 この値が後で追加された場合、既存の環境のプランは更新されません。既存の環境のプランを更新するには、 Environments API を使用する必要があります。 CI/CD 変数 を使用して、環境名を動的に指定します。 deploy as review app ジョブは、 review/$CI_COMMIT_REF_SLUG 環境を動的に作成するためのデプロイとしてマークされます。 $CI_COMMIT_REF_SLUG は、Runnerによって設定される CI/CD変数 です。 $CI_ENVIRONMENT_SLUG 変数は環境名に基づいていますが、URLに含めるのに適しています。 pow というブランチで deploy as review app ジョブが実行される場合、この環境は https://review-pow.example.com/ のようなURLでアクセスできるようになります。 一般的なユースケースは、ブランチの動的環境を作成し、それらをレビューアプリとして使用することです。レビューアプリの使用例は、 https://gitlab.com/gitlab-examples/review-apps-nginx/ で確認できます。 extends を使用して、設定セクションを再利用します。これは YAMLアンカー の代替手段であり、わずかに柔軟性が高く、読みやすくなっています。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 パイプライン内の別のジョブの名前。 パイプライン内の他のジョブの名前のリスト（配列）。 この例では、 rspec ジョブが .tests テンプレートジョブの設定を使用します。パイプラインの作成時に、GitLabは次の処理を行います。 キーに基づいて逆ディープマージを実行します。 .tests の内容を rspec ジョブとマージします。 結合された設定は、以下のジョブと同等です。 extends には複数の親を使用できます。 extends キーワードは最大11レベルの継承をサポートしていますが、4レベル以上を使用することは避けてください。 前述の例では、 .tests は 非表示ジョブ ですが、通常のジョブから設定を拡張することもできます。 extends を使用して設定セクションを再利用する 。 extends を使用して、 インクルードされた設定ファイル の設定を再利用する。 hooks を使用して、ジョブ実行の特定のステージ（Gitリポジトリを取得する前など）で、Runnerで実行するコマンドのリストを指定します。 ジョブの設定とデフォルト設定は一緒にマージされません。パイプラインに default:hooks が定義されていて、ジョブにも hooks がある場合、ジョブの設定が優先され、デフォルト設定は使用されません。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 フックとそのコマンドのハッシュ。利用可能なフック: pre_get_sources_script 。 hooks:pre_get_sources_script hooks:pre_get_sources_script を使用して、Gitリポジトリとサブモジュールをクローンする前にRunnerで実行するコマンドのリストを指定します。たとえば、次のような用途に使用できます。 トレーシング変数 をエクスポートする。 サポートされている値 : 次の内容を含む配列。 複数行に分割された 長いコマンド。 CI/CD変数が サポートされています 。 hooks:pre_get_sources_script の例 : GitLab Runnerの設定 プラン : Free、Premium、Ultimate 提供形態 : GitLab.com GitLab 16.9で google_cloud_support_feature_flag 機能フラグ とともに 導入 されました。この機能は ベータ版 です。 GitLab 17.1の GitLab.comで有効 になりました。機能フラグ google_cloud_support_feature_flag は削除されました。 identity を使用して、アイデンティティフェデレーションを使用したサードパーティサービスの認証を行います。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 識別子。サポートされているプロバイダーは以下のとおりです。 google_cloud : Google Cloud。 Google Cloud IAMインテグレーション を使用して設定する必要があります。 Workload Identity連携 。 Google Cloud IAMインテグレーション 。 id_tokens を使用して、サードパーティサービスの認証を行うための IDトークン を作成します。この方法で作成されたすべてのJSON Webトークンは、OIDC認証をサポートしています。JSON Webトークンの aud クレームを設定するために、必須のサブキーワード aud を使用します。 ジョブの設定とデフォルト設定は一緒にマージされません。パイプラインに default:id_tokens が定義されていて、ジョブにも id_tokens がある場合、ジョブの設定が優先され、デフォルト設定は使用されません。 トークン名と、その aud クレーム。 aud では以下がサポートされています。 単一の文字列。 文字列の配列。 CI/CD変数 。 クラウドサービスに接続する 。 キーレス署名にSigstoreを使用する 。 image を使用して、ジョブが実行されるDockerイメージを指定します。 ジョブの設定とデフォルト設定は一緒にマージされません。パイプラインに default:image が定義されていて、ジョブにも image がある場合、ジョブの設定が優先され、デフォルト設定は使用されません。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 サポートされている値 : イメージ名（必要に応じてレジストリパスを含む）。次のいずれかの形式で指定します。 <image-name> （ <image-name> に latest タグを付けた場合と同じ） <image-name>:<tag> <image-name>@<digest> CI/CD変数が サポートされています 。 この例では、 ruby:3.0 イメージがパイプライン内のすべてのジョブに対するデフォルトです。 rspec 2.7 ジョブは、ジョブ固有の image セクションでデフォルトをオーバーライドするため、デフォルトを使用しません。 トップレベルで image を使用しても、 default セクションでは使用しない場合、 非推奨 になります。 DockerコンテナでCI/CDジョブを実行する 。 ジョブが実行されるDockerイメージの名前。 image を単独で使用した場合と同様に機能します。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 サポートされている値 : イメージ名（必要に応じてレジストリパスを含む）。次のいずれかの形式で指定します。 <image-name> （ <image-name> に latest タグを付けた場合と同じ） <image-name>:<tag> <image-name>@<digest> CI/CD変数が サポートされています 。 image:name の例 : DockerコンテナでCI/CDジョブを実行する 。 image:entrypoint コンテナのエントリポイントとして実行するコマンドまたはスクリプト。 Dockerコンテナの作成時に、 entrypoint はDockerの --entrypoint オプションに変換されます。構文は Dockerfileの ENTRYPOINT ディレクティブ に似ており、各Shellトークンは配列内の個別の文字列です。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 image:entrypoint の例 : イメージのエントリポイントをオーバーライドする 。 image:docker を使用して、 Docker executor または Kubernetes executor を使用するRunnerにオプションを渡します。このキーワードは、他のexecutorタイプでは機能しません。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 Docker executorのオプションを定義するハッシュ。以下を含めることができます。 platform : プルするイメージのアーキテクチャを選択します。指定しない場合、デフォルトはホストRunnerと同じプラットフォームです。 user : コンテナの実行時に使用するユーザー名またはUIDを指定します。 image:docker の例 : image:docker:platform は、 docker pull --platform オプション にマップされます。 image:docker:user は、 docker run --user オプション にマップされます。 image:kubernetes GitLab 18.0で 導入 されました。GitLab Runner 17.11以降が必要です。 user インプットオプションは、GitLab Runner 17.11で 導入 されました。 user インプットオプションは、GitLab 18.0で uid:gid 形式をサポートするように拡張 されました。 image:kubernetes を使用して、GitLab Runner Kubernetes executor にオプションを渡します。このキーワードは、他のexecutorタイプでは機能しません。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 Kubernetes executorのオプションを定義するハッシュ。以下を含めることができます。 user : コンテナの実行時に使用するユーザー名またはUIDを指定します。 UID:GID 形式を使用して、GIDを設定することもできます。 UIDのみを使用した image:kubernetes の例 : UIDとGIDの両方を使用した image:kubernetes の例 : image:pull_policy RunnerがDockerイメージをフェッチするために使用するプルポリシー。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 1つのプルポリシー、または配列で指定する複数のプルポリシー。 always 、 if-not-present 、 never のいずれかを指定できます。 image:pull_policy の例 : 定義済みのプルポリシーをRunnerがサポートしていない場合、ジョブは次のようなエラーで失敗します: ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never]) 。 DockerコンテナでCI/CDジョブを実行する 。 Runnerがイメージをプルする方法を設定する 。 複数のプルポリシーを設定する 。 GitLab 18.10で 導入 されました。 ジョブの型付き検証済み入力を定義するには、 inputs を使用します。手動でジョブを実行または再試行する際に、 ジョブインプット を上書きできます。 ジョブインプットは、型安全性と検証を提供するパラメータです。 CI/CD変数 とは異なり、ジョブの実行または再試行時に指定できるのは、ジョブで明示的に定義された入力のみです。すべてのジョブ入力名は事前定義されている必要があります。 ${{ job.inputs.INPUT_NAME }} Moa 構文でジョブ入力値を参照します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 各入力が1つ以上のサブキーで設定された入力名のハッシュ: ジョブインプットは、ジョブが作成される際、および新しい入力値でジョブを再試行する際に検証されます。検証が失敗した場合、ジョブは開始されません。 ジョブインプットは、定義されたジョブにスコープされており、他のジョブからアクセスすることはできません。 ジョブ入力をサポートするキーワードの完全なリストについては、 ジョブ入力を使用できる場所 を参照してください。 すべてのジョブ入力は、 default で定義されたデフォルト値を持っている必要があります。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 入力の type に一致する任意の値。 inputs:default の例 : 入力値のデータ型を定義するには、 type を使用します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 inputs:type の例 : inputs:description 入力の目的についての情報を提供するには、 description を使用します。説明は入力の動作に影響しません。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 文字列。 inputs:description の例 : 入力に許可される値のリストを指定するには、 options を使用します。 入力値は、リストされたオプションのいずれかに正確に一致する必要があります（大文字と小文字を区別）。値がオプションに一致しない場合、検証は失敗します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 許可された値の配列。 inputs:options の例 : 入力値が一致する必要がある正規表現パターンを指定するには、 regex を使用します。 値が正規表現に一致しない場合、検証は失敗します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 正規表現文字列。 inputs:regex の例 : この例では、 v1.1.1 の入力値は正規表現検証を通過しますが、 v1.1.1-beta の入力は通過しません。 inherit を使用して、 デフォルトのキーワードと変数の継承を制御します 。 inherit:default inherit:default を使用して、 デフォルトのキーワード の継承を制御します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 true （デフォルト）、または false 。すべてのデフォルトキーワードの継承を有効または無効にします。 継承する特定のデフォルトキーワードのリスト。 inherit:default の例 : 継承するデフォルトキーワードを1行で記述することもできます: default: [keyword1, keyword2] inherit:variables inherit:variables を使用して、 デフォルト変数 のキーワードの継承を制御します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 true （デフォルト）、または false 。すべてのデフォルト変数の継承を有効または無効にします。 inherit:variables の例 : 継承するデフォルト変数を1行で記述することもできます: variables: [VARIABLE1, VARIABLE2] interruptible を使用して、 冗長なパイプラインを自動キャンセル する機能を設定します。この機能は、新しいコミットに対して同じref上で新しいパイプラインが開始された場合、ジョブが完了する前にそのジョブをキャンセルします。この機能が無効になっている場合、このキーワードは効果がありません。新しいパイプラインは、新しい変更を含むコミットに対して開始されたものである必要があります。たとえば、UIで 新しいパイプライン を選択して同じコミットに対してパイプラインを実行した場合、 冗長なパイプラインを自動キャンセル する機能は適用されません。 冗長なパイプラインを自動キャンセル 機能の動作は workflow:auto_cancel:on_new_commit 設定で制御できます。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 true または false （デフォルト）。 デフォルトの動作を使用する interruptible の例 : この例では、新しいパイプラインが実行中のパイプラインに次のような影響を及ぼします。

step-1 のみが実行中または保留中の場合は、キャンセルされます。 step-2 の開始後は、キャンセルされません。 auto_cancel:on_new_commit:interruptible 設定を使用した interruptible の例 : この例では、新しいパイプラインによって、実行中のパイプラインが実行中または保留中の step-1 と step-3 をキャンセルします。 ビルドジョブのように、ジョブを開始した後でもジョブを安全にキャンセルできる場合にのみ、 interruptible: true を設定してください。部分的なデプロイを防ぐため、デプロイメントジョブは通常、キャンセルすべきではありません。 デフォルトの動作（ workflow:auto_cancel:on_new_commit: conservative ）を使用する場合: まだ開始されていないジョブは、ジョブの設定に関係なく常に interruptible: true と見なされます。 interruptible 設定は、ジョブの開始後にのみ考慮されます。 実行中 のパイプラインがキャンセルされるのは、実行中のすべてのジョブで interruptible: true が設定されているか、 interruptible: false が設定されたジョブが一度も開始されていない場合のみです。 interruptible: false と指定されたジョブが開始されると、パイプライン全体が中断不可と見なされます。 パイプラインがダウンストリームパイプラインをトリガーした場合でも、ダウンストリームパイプライン内で interruptible: false が設定されたジョブがまだ開始されていなければ、ダウンストリームパイプラインもキャンセルされます。 まだ開始されていないジョブは、ジョブの設定に関係なく常に interruptible: true と見なされます。 interruptible 設定は、ジョブの開始後にのみ考慮されます。 実行中 のパイプラインがキャンセルされるのは、実行中のすべてのジョブで interruptible: true が設定されているか、 interruptible: false が設定されたジョブが一度も開始されていない場合のみです。 interruptible: false と指定されたジョブが開始されると、パイプライン全体が中断不可と見なされます。 パイプラインがダウンストリームパイプラインをトリガーした場合でも、ダウンストリームパイプライン内で interruptible: false が設定されたジョブがまだ開始されていなければ、ダウンストリームパイプラインもキャンセルされます。 interruptible: false が設定されたオプションの手動ジョブをパイプラインの最初のステージに追加すると、ユーザーがパイプラインの自動キャンセルを手動で防止できるようになります。ユーザーがこのジョブを開始すると、 冗長なパイプラインを自動キャンセル する機能でそのパイプラインをキャンセルすることはできません。 トリガージョブ で interruptible を使用する場合: トリガーされたダウンストリームパイプラインは、トリガージョブの interruptible 設定の影響を受けません。 workflow:auto_cancel が conservative に設定されている場合、トリガージョブの interruptible 設定は無効です。 workflow:auto_cancel が interruptible に設定されている場合、 interruptible: true が設定されたトリガージョブは自動キャンセルできます。 トリガーされたダウンストリームパイプラインは、トリガージョブの interruptible 設定の影響を受けません。 workflow:auto_cancel が conservative に設定されている場合、トリガージョブの interruptible 設定は無効です。 workflow:auto_cancel が interruptible に設定されている場合、 interruptible: true が設定されたトリガージョブは自動キャンセルできます。 needs を使用して、ジョブを順不同で実行します。 needs を使用するジョブ間の関係は、 有向非巡回グラフ として視覚化できます。 ステージの順序を無視して、他のジョブの完了を待たずに一部のジョブを実行できます。複数のステージのジョブを同時に実行できます。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 ジョブの配列（最大で50のジョブを指定可能）。 空の配列（ [] ）。パイプラインの作成後、すぐにジョブを開始するために設定します。 この例では、4つの実行パスを作成します。 Linter: lint ジョブは、ニーズがないため（ needs: [] ）、 build ステージの完了を待たずにすぐ実行されます。 Linuxパス: linux:rspec ジョブは、 mac:build の完了を待たずに、 linux:build ジョブが完了するとすぐに実行されます。 macOSパス: mac:rspec ジョブは、 linux:build の完了を待たずに、 mac:build ジョブの完了後すぐに実行されます。 production ジョブは、それ以前のすべてのジョブ（ lint 、 linux:build 、 linux:rspec 、 mac:build 、 mac:rspec ）の完了後すぐに実行されます。 単一のジョブが needs 配列に指定できるジョブの最大数には、次の制限があります。 GitLab.comの場合、上限は50です。詳細については、 イシュー350398 を参照してください。 GitLab Self-ManagedおよびGitLab Dedicatedの場合、デフォルトの制限は50です。この制限は、 管理者エリアでCI/CD制限を更新 することで変更できます。 GitLab.comの場合、上限は50です。詳細については、 イシュー350398 を参照してください。 GitLab Self-ManagedおよびGitLab Dedicatedの場合、デフォルトの制限は50です。この制限は、 管理者エリアでCI/CD制限を更新 することで変更できます。 needs が parallel キーワードを使用するジョブを参照している場合、それは1つのジョブだけでなく、並列に作成されるすべてのジョブに依存します。また、デフォルトでは、すべての並列ジョブからアーティファクトをダウンロードします。同じ名前のアーティファクトがある場合、上書きすることになり、最後にダウンロードしたアーティファクトだけが保存されます。 needs に（並列ジョブのすべてではなく）並列ジョブの一部のみを参照させるには、 needs:parallel:matrix キーワードを使用します。 needs に（並列ジョブのすべてではなく）並列ジョブの一部のみを参照させるには、 needs:parallel:matrix キーワードを使用します。 設定対象のジョブと同じステージのジョブを参照できます。 needs が only 、 except 、 rules の条件によりパイプラインに追加されない可能性があるジョブを参照する場合、パイプラインの作成に失敗する可能性があります。このパイプライン作成の失敗を解決するには、 needs:optional キーワードを使用します。 パイプラインに needs: [] を指定したジョブと .pre ステージのジョブがある場合、これらはすべてパイプラインの作成直後に開始されます。 needs: [] を指定したジョブはすぐに開始され、 .pre ステージのジョブもすぐに開始されます。 needs:artifacts ジョブで needs を使用すると、デフォルトでは、それ以前のステージからすべてのアーティファクトをダウンロードすることはなくなります。 needs を指定したジョブは、それ以前のステージの完了前に開始される可能性があるからです。 needs を使用する場合、 needs の設定で指定したジョブからのみアーティファクトをダウンロードできます。 needs を使用するジョブでアーティファクトをダウンロードするタイミングを制御するには、 artifacts: true （デフォルト）または artifacts: false を使用します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 needs:job と一緒に使用する必要があります。 true （デフォルト）または false 。 needs:artifacts の例 : test-job1 ジョブは build_job1 のアーティファクトをダウンロードします。 test-job2 ジョブは build_job2 のアーティファクトをダウンロードしません。 test-job3 ジョブは、3つの build_jobs すべてからアーティファクトをダウンロードします。必要なすべてのジョブで、 artifacts に true が指定されているか、またはデフォルトで true になっているためです。 同じジョブの中で needs を dependencies と組み合わせて使用しないでください。 プラン : Premium、Ultimate 提供形態 : GitLab.com、GitLab Self-Managed、GitLab Dedicated needs:project を使用して、他のパイプライン内の最大5つのジョブからアーティファクトをダウンロードします。アーティファクトは、指定されたref上で最後に成功した指定ジョブからダウンロードされます。複数のジョブを指定するには、 needs キーワードの下にそれぞれ個別の配列項目として追加します。 指定されたrefに対して実行中のパイプラインがある場合、 needs:project を使用するジョブはそのパイプラインの完了を待機しません。代わりに、指定されたジョブの最後に成功した実行結果からアーティファクトをダウンロードします。 needs:project は、 job 、 ref 、 artifacts と一緒に使用する必要があります。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 needs:project : ネームスペースとグループを含む、プロジェクトのフルパス。 job : アーティファクトのダウンロード元のジョブ。 ref : アーティファクトのダウンロード元のref。 artifacts : アーティファクトをダウンロードするには、 true に設定する必要があります。 needs:project の例 : この例では、 build_job は、 group/project-name および group/project-name-2 プロジェクトの main ブランチにおいて、最後に成功した build-1 および build-2 ジョブからアーティファクトをダウンロードします。 needs:project では CI/CD変数 を使用できます。次に例を示します。 現在のプロジェクト内の別のパイプラインからアーティファクトをダウンロードするには、 project に現在のプロジェクトと同じ値を指定し、現在のパイプラインとは異なるrefを使用します。同じref上で複数のパイプラインが同時に実行されていると、アーティファクトが上書きされる可能性があります。 パイプラインを実行するユーザーは、グループまたはプロジェクトのレポーター、デベロッパー、メンテナー、またはオーナーロールを持っている必要があります。あるいは、グループ/プロジェクトが公開表示レベルである必要があります。 needs:project と trigger は、同じジョブ内で併用できません。 needs:project を使用して別のパイプラインからアーティファクトをダウンロードする場合、ジョブは必要なジョブが完了するのを待機しません。 needs を使用してジョブの完了を待機する 動作は、同じパイプライン内のジョブに限定されます。そのため、ジョブがアーティファクトをダウンロードしようとする前に、他のパイプライン内の必要なジョブが完了していることを確認してください。 parallel で実行されるジョブからアーティファクトをダウンロードすることはできません。 project 、 job 、 ref では CI/CD変数 をサポートしています。 親子パイプライン 間でアーティファクトをダウンロードするには、 needs:pipeline:job を使用します。 needs:pipeline:job 子パイプライン は、親パイプラインまたは同じ親子パイプライン階層にある別の子パイプラインの正常に完了したジョブからアーティファクトをダウンロードできます。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 needs:pipeline : パイプラインID。同じ親子パイプライン階層に属するパイプラインである必要があります。 job : アーティファクトのダウンロード元のジョブ。 needs:pipeline:job の例 : 親パイプライン（ .gitlab-ci.yml ）: stages : - build - test create-artifact : stage : build script : echo "sample artifact" > artifact.txt artifacts : paths : [ artifact.txt] child-pipeline : stage : test trigger : include : child.yml strategy : mirror variables : PARENT_PIPELINE_ID : $CI_PIPELINE_ID 親パイプライン（ .gitlab-ci.yml ）: 子パイプライン（ child.yml ）: use-artifact : script : cat artifact.txt needs : - pipeline : $PARENT_PIPELINE_ID job : create-artifact 子パイプライン（ child.yml ）: この例では、親パイプライン内の create-artifact ジョブがアーティファクトを作成します。 child-pipeline ジョブは子パイプラインをトリガーし、 CI_PIPELINE_ID 変数を新しい PARENT_PIPELINE_ID 変数として子パイプラインに渡します。子パイプラインは、この変数を needs:pipeline に使用することで、親パイプラインからアーティファクトをダウンロードできます。後続のステージに create-artifact ジョブと child-pipeline ジョブを配置することで、 create-artifact が正常に完了した場合にのみ use-artifact ジョブが実行されるようになります。 pipeline 属性は、現在のパイプラインID（ $CI_PIPELINE_ID ）を受け付けません。現在のパイプライン内のジョブからアーティファクトをダウンロードするには、 needs:artifacts を使用します。 needs:pipeline:job を トリガージョブ で使用することはできず、 マルチプロジェクトパイプライン からアーティファクトをフェッチするために使用することもできません。マルチプロジェクトパイプラインからアーティファクトをフェッチするには、 needs:project を使用します。 needs:pipeline:job にリストされているジョブは、 success で完了する必要があります。そうなっていない場合、アーティファクトをフェッチできません。 イシュー367229 では、アーティファクトを持つ任意のジョブからアーティファクトをフェッチできるようにする提案がなされています。 パイプライン中に存在しないことのあるジョブを必須とするには、 needs の設定に optional: true を追加します。定義されていない場合、 optional: false がデフォルトです。 rules 、 only 、または except を使用しているジョブや、 include によって追加されたジョブは、常にパイプラインに追加されるとは限りません。GitLabは、パイプラインを開始する前に needs の関係をチェックします。 needs エントリに optional: true が設定され、必要なジョブがパイプラインに存在する場合、ジョブはその完了を待ってから開始します。 必要なジョブが存在しない場合、ジョブは他のすべてのneeds要件が満たされた時点で開始できます。 needs セクションにオプションのジョブのみが含まれており、いずれもパイプラインに追加されていない場合、そのジョブはすぐに開始されます（空の needs エントリである needs: [] を指定した場合と同じ）。 必要なジョブに optional: false が指定されているが、パイプラインに追加されなかった場合、パイプラインの開始は失敗し、次のようなエラーになります: 'job1' job needs 'job2' job, but it was not added to the pipeline 。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 needs:optional の例 : build-job 、 test-job1 、 test-job2 は、ステージの順に開始します。 ブランチがデフォルトブランチの場合、 test-job2 がパイプラインに追加されるため、次のようになります。 deploy-job は、 test-job1 と test-job2 の両方が完了するのを待機します。 review-job は、 test-job2 が完了するのを待機します。 deploy-job は、 test-job1 と test-job2 の両方が完了するのを待機します。 review-job は、 test-job2 が完了するのを待機します。 ブランチがデフォルトブランチでない場合、 test-job2 はパイプラインに追加されないため、次のようになります。 deploy-job は test-job1 の完了のみを待機し、存在しない test-job2 の完了は待機しません。 review-job には他に必要なジョブがないため、 needs: [] と同様に、すぐに（ build-job と同時に）開始されます。 deploy-job は test-job1 の完了のみを待機し、存在しない test-job2 の完了は待機しません。 review-job には他に必要なジョブがないため、 needs: [] と同様に、すぐに（ build-job と同時に）開始されます。 needs:optional を needs:parallel:matrix と一緒に使用することはできません。 needs:pipeline キーワードを使用すると、アップストリームパイプラインからジョブにパイプラインのステータスをミラーリングできます。デフォルトブランチからの最新のパイプラインステータスが、ジョブにレプリケートされます。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 ネームスペースとグループを含む、プロジェクトのフルパス。プロジェクトが同じグループまたはネームスペースに含まれる場合は、 project キーワードからそれらを省略できます。例: project: group/project-name または project: project-name 。 needs:pipeline の例 : job キーワードを needs:pipeline に追加すると、ジョブはパイプラインステータスをミラーリングしなくなります。動作は needs:pipeline:job に変わります。 needs:parallel:matrix ジョブで parallel:matrix を使用すれば、単一のパイプラインで1つのジョブを複数のインスタンスとして同時実行し、ジョブのインスタンスごとに異なる変数値を使用できます。 needs:parallel:matrix を使用して、複数の並列ジョブに応じてジョブを順不同で実行します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 needs:job と一緒に使用する必要があります。 サポートされている値 : マトリックス識別子のハッシュの配列: 識別子と値は、 parallel:matrix ジョブで定義された識別子と値から選択する必要があります。 マトリックス式 を使用できます。 needs:parallel:matrix の例 : 前述の例では、次のジョブが生成されます。 linux:rspec ジョブは、 linux:build: [aws, app1] ジョブが完了するとすぐに実行されます。 needs:parallel:matrix を needs:optional と一緒に使用することはできません。 needs:parallel:matrix を needs:optional と一緒に使用することはできません。 needs:parallel:matrix のマトリックス識別子の順序は、必要なジョブのマトリックス変数の順序と一致する必要があります。たとえば、前述の例の linux:rspec ジョブで、変数の順序を逆にすると無効になります。 linux:rspec : stage : test needs : - job : linux:build parallel : matrix : - STACK : app1 # The variable order does not match `linux:build` and is invalid. PROVIDER : aws script : echo "Running rspec on linux..." needs:parallel:matrix のマトリックス識別子の順序は、必要なジョブのマトリックス変数の順序と一致する必要があります。たとえば、前述の例の linux:rspec ジョブで、変数の順序を逆にすると無効になります。 複数の並列ジョブが存在する状況でneedsを使用して特定の並列ジョブを指定する 。 needs:parallel:matrix のマトリックス式 。 pages を使用して、静的コンテンツをGitLabにアップロードする GitLab Pages ジョブを定義します。コンテンツはウェブサイトとして公開されます。 次のことを行う必要があります。 pages: true を定義し、 public という名前のディレクトリを公開します。 別のコンテンツディレクトリを使用する場合は、代わりに pages.publish を定義します。 コンテンツディレクトリのルートに空ではない index.html ファイルを配置します。 キーワードのタイプ : ジョブキーワード、またはジョブ名（非推奨）。ジョブの一部としてのみ使用できます。 ブール値。 true に設定すると、デフォルトの設定を使用します。 設定オプションのハッシュ。詳細については、この後のセクションを参照してください。 この例では、 my-html-content/ ディレクトリの名前を public/ に変更しています。このディレクトリはアーティファクトとしてエクスポートされ、GitLab Pagesで公開されます。 この例では、ディレクトリは移動せず、 publish プロパティを直接使用しています。また、このページデプロイが1週間後に非公開になるよう設定しています。 pages をジョブ名として使用することは 非推奨 です。 Pagesのデプロイをトリガーせずに pages をジョブ名として使用するには、 pages プロパティをfalseに設定します。 GitLab 17.9で、 publish プロパティに渡す際に変数を利用できるように 変更 されました。 GitLab 17.9で、 publish プロパティが pages キーワードの下に 移動 されました。 GitLab 17.10で、 pages.publish パスが artifacts:paths に自動的に 付加 されるようになりました。 pages.publish を使用して、 pages ジョブ のコンテンツディレクトリを設定します。 キーワードのタイプ : ジョブキーワード。これは、 pages ジョブの一部としてのみ使用できます。 サポートされている値 : Pagesコンテンツを含むディレクトリのパス。 GitLab 17.10以降 、これを指定しない場合、デフォルトの public ディレクトリが使用されます。指定した場合、そのパスが自動的に artifacts:paths に付加されます。 pages.publish の例 : この例では、 Eleventy を使用して静的ウェブサイトを生成し、生成されたHTMLファイルを dist/ ディレクトリに出力しています。このディレクトリはアーティファクトとしてエクスポートされ、GitLab Pagesで公開されます。 pages.publish フィールドでは変数も使用できます。例: 指定する公開パスは、ビルドのルートからの相対パスでなければなりません。 トップレベルキーワード publish は 非推奨 となっており、現在は pages キーワードの下にネストされた状態にする必要があります。 pages.path_prefix プラン : Premium、Ultimate 提供形態 : GitLab.com、GitLab Self-Managed、GitLab Dedicated GitLab 16.7で、 pages_multiple_versions_setting という 機能フラグ を持つ 実験 として 導入 されました（デフォルトでは無効）。 GitLab 17.4の GitLab.com、GitLab Self-Managed、GitLab Dedicatedで有効 になりました。 GitLab 17.8で、ピリオドを許可するように 変更 されました。 GitLab 17.9で 一般提供 になりました。機能フラグ pages_multiple_versions_setting は削除されました。 pages.path_prefix を使用して、GitLab Pagesの 並列デプロイ のパスプレフィックスを設定します。 キーワードのタイプ : ジョブキーワード。これは、 pages ジョブの一部としてのみ使用できます。 指定された値は小文字に変換され、63バイトに短縮されます。英数字とピリオド以外の文字はすべてハイフンに置き換えられます。先頭および末尾にハイフンまたはピリオドを含めることはできません。 pages.path_prefix の例 : この例では、ブランチごとに異なるページデプロイが作成されます。 pages.expire_in プラン : Premium、Ultimate 提供形態 : GitLab.com、GitLab Self-Managed、GitLab Dedicated GitLab 17.4で 導入 されました。 変数のサポートは、GitLab 17.11で 導入 されました。 expire_in を使用して、デプロイが期限切れになるまでの有効期間を指定します。デプロイが期限切れになると、10分ごとに実行されるcronジョブによって非アクティブ化されます。 デフォルトでは、 並列デプロイ は24時間後に自動的に期限切れになります。この動作を無効にするには、値を never に設定します。 キーワードのタイプ : ジョブキーワード。これは、 pages ジョブの一部としてのみ使用できます。 サポートされている値 : 有効期間。単位が指定されていない場合は秒単位です。変数もサポートされています。有効な値の例は以下のとおりです。 47 yrs 6 mos and 4d 3 weeks and 2 days pages.expire_in の例 : parallel を使用して、1つのパイプラインで同じジョブを複数並列に実行します。 複数のRunnerが存在する必要があります。または、単一のRunnerが複数のジョブを同時に実行するよう設定されている必要があります。 並列ジョブには、 job_name 1/N から job_name N/N までの連番の名前が付けられます。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 1 から 200 までの数値。 この例では、並列に実行される5つのジョブが作成され、それぞれ test 1/5 から test 5/5 という名前が付けられます。 どの並列ジョブにも、 CI_NODE_INDEX および CI_NODE_TOTAL という 定義済みのCI/CD変数 が設定されています。 parallel を使用するジョブを含むパイプラインでは、次のような状況が発生する可能性があります。 利用可能なRunner数を超える並列実行ジョブが作成されることがあります。超過したジョブはキューに入れられ、Runnerが利用可能になるまで待機している間、 pending のマークが付けられます。 パイプラインを作成すると、すべてのアクティブなパイプライン全体のジョブの合計数が インスタンス制限を超える 場合、 job_activity_limit_exceeded エラーで失敗します。 利用可能なRunner数を超える並列実行ジョブが作成されることがあります。超過したジョブはキューに入れられ、Runnerが利用可能になるまで待機している間、 pending のマークが付けられます。 パイプラインを作成すると、すべてのアクティブなパイプライン全体のジョブの合計数が インスタンス制限を超える 場合、 job_activity_limit_exceeded エラーで失敗します。 大規模なジョブを並列化する 。 parallel:matrix parallel:matrix を使用して、1つのパイプラインで同じジョブを複数並列に実行し、ジョブのインスタンスごとに異なる変数値を指定します。 複数のRunnerが存在する必要があります。または、単一のRunnerが複数のジョブを同時に実行するよう設定されている必要があります。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 変数のハッシュの配列。 マトリックス識別子（変数名になります）に使用できるのは、数字、文字、アンダースコア（ _ ）のみです。 値は文字列、または文字列の配列でなければなりません。 順列の数は200以下でなければなりません。 parallel:matrix の例 : この例では、 PROVIDER と STACK の値が異なる7個の並列 deploystacks ジョブが生成されます。 deploystacks: [aws, monitoring] deploystacks: [aws, app1] deploystacks: [aws, app2] deploystacks: [gcp, data] deploystacks: [gcp, processing] deploystacks: [vultr, data] deploystacks: [vultr, processing] parallel:matrix ジョブは、ジョブを区別するためにマトリックス値をジョブ名に追加します。しかし、長い値はジョブ名が255文字の制限を超える原因となる可能性があります。詳細については、 エピック11791 を参照してください。 parallel:matrix ジョブは、ジョブを区別するためにマトリックス値をジョブ名に追加します。しかし、長い値はジョブ名が255文字の制限を超える原因となる可能性があります。詳細については、 エピック11791 を参照してください。 マトリックス変数値は、 rules:if 式でCI/CD変数として利用できます。詳細については、 matrix変数を rules:if で使用する を参照してください。 マトリックス変数値は、 rules:if 式でCI/CD変数として利用できます。詳細については、 matrix変数を rules:if で使用する を参照してください。 同じ値で異なる名前を指定して複数のマトリックス設定を作成することはできません。ジョブ名は名前ではなくマトリックス値から生成されるため、マトリックスエントリが同じなら、同一のジョブ名が生成されて互いに上書きすることになります。 たとえば、次の test 設定では、同一のジョブで構成される2つのシリーズを作成しようとしていますが、 OS2 バージョンのジョブが OS バージョンのジョブを上書きすることになります。 test : parallel : matrix : - OS : [ ubuntu] PROVIDER : [ aws, gcp] - OS2 : [ ubuntu] PROVIDER : [ aws, gcp] 同じ値で異なる名前を指定して複数のマトリックス設定を作成することはできません。ジョブ名は名前ではなくマトリックス値から生成されるため、マトリックスエントリが同じなら、同一のジョブ名が生成されて互いに上書きすることになります。 たとえば、次の test 設定では、同一のジョブで構成される2つのシリーズを作成しようとしていますが、 OS2 バージョンのジョブが OS バージョンのジョブを上書きすることになります。 並列ジョブの1次元マトリックスを実行する 。 並列トリガージョブのマトリックスを実行する 。 並列マトリックスジョブごとに異なるRunnerタグを選択する 。 ルールでmatrix変数を使用する 。 needs:parallel:matrix のマトリックス式 。 release を使用して、 リリース を作成します。 リリースジョブは、 glab CLI にアクセスできる必要があり、これは $PATH にある必要があります。 Docker executor を使用する場合は、次のGitLabコンテナレジストリにあるDockerイメージを使用できます: registry.gitlab.com/gitlab-org/cli:latest Shell executor などを使用する場合は、Runnerが登録されているサーバーに glab CLIをインストール します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : release サブキー。 tag_message （オプション） milestones （オプション） released_at （オプション） assets:links （オプション） release キーワードの例 : この例では、次のタイミングでリリースを作成します。 Gitタグをプッシュしたとき。 UIで コード > タグ からGitタグを追加したとき。 リリースジョブには script キーワードを含める必要があります。リリースジョブでは、スクリプト型コマンドからの出力を使用できます。スクリプトが不要な場合は、次のようにプレースホルダーを使用できます。 script : - echo "release job" この制限を削除することを目的とした イシュー223856 を参照してください。 リリースジョブには script キーワードを含める必要があります。リリースジョブでは、スクリプト型コマンドからの出力を使用できます。スクリプトが不要な場合は、次のようにプレースホルダーを使用できます。 この制限を削除することを目的とした イシュー223856 を参照してください。 release セクションは、 script キーワードの後、 after_script の前に実行されます。 release セクションは、 script キーワードの後、 after_script の前に実行されます。 リリースが作成されるのは、ジョブのメインスクリプトが成功した場合のみです。 リリースが作成されるのは、ジョブのメインスクリプトが成功した場合のみです。 同じリリースがすでに存在する場合、そのリリースは更新されず、 release キーワードを含むジョブは失敗します。 同じリリースがすでに存在する場合、そのリリースは更新されず、 release キーワードを含むジョブは失敗します。 release キーワードのCI/CDの例 。 単一のパイプラインで複数のリリースを作成する 。 カスタムSSL CA認証局を使用する 。 release:tag_name 必須。リリースのGitタグです。 このタグがまだプロジェクト内に存在しない場合、リリースの作成と同時にタグも作成されます。新しいタグは、パイプラインに関連付けられたSHAを使用します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 CI/CD変数が サポートされています 。 release:tag_name の例 : 新しいタグがプロジェクトに追加された時点でリリースを作成するには、次のようにします。 tag_name としてCI/CD変数 $CI_COMMIT_TAG を使用します。 rules:if を使用して、新しいタグに対してのみジョブを実行するよう設定します。 リリースと新しいタグを同時に作成するには、 rules が新しいタグのみでジョブを実行するように設定しないようにする必要があります。セマンティックバージョニングの例を以下に示します。 release:tag_message タグが存在しない場合、新しく作成されるタグには、 tag_message で指定されているメッセージが注釈として付けられます。省略した場合、軽量タグが作成されます。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 release:tag_message の例 : リリース名。省略した場合、 release: tag_name の値が入力されます。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 release:name の例 : release:description キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 説明を含むファイルのパス。 そのファイルの場所は、プロジェクトディレクトリ（ $CI_PROJECT_DIR ）からの相対パスでなければなりません。 ファイルがシンボリックリンクの場合、 $CI_PROJECT_DIR 内に存在する必要があります。 ./path/to/file とファイル名にスペースを含めることはできません。 そのファイルの場所は、プロジェクトディレクトリ（ $CI_PROJECT_DIR ）からの相対パスでなければなりません。 ファイルがシンボリックリンクの場合、 $CI_PROJECT_DIR 内に存在する必要があります。 ./path/to/file とファイル名にスペースを含めることはできません。 release:description の例 : description は、 glab を実行するShellによって評価されます。説明の定義にはCI/CD変数を使用できますが、一部のShellでは変数を参照するための 構文が異なることがあります 。同様に、Shellによっては特殊文字をエスケープする必要があります。たとえば、バッククォート（ ` ）をバックスラッシュ（ \ ）でエスケープしなければならない場合があります。 release: tag_name がまだ存在しない場合に使用されるリリースの ref です。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 コミットSHA、別のタグ名、またはブランチ名。 release:milestones リリースが関連付けられている各マイルストーンのタイトル。 release:released_at リリースが準備完了になる日時。 ISO 8601形式の日付（引用符で囲む）。 release:released_at の例 : 定義されていない場合は、現在の日時が使用されます。 release:assets:links release:assets:links を使用して、リリースに アセットリンク を含めます。 release:assets:links の例 : resource_group を使用して、同じプロジェクトの異なるパイプライン間で、ジョブが相互に排他的に実行されるようにするための リソースグループ を作成します。 たとえば、同じリソースグループに属する複数のジョブが同時にキューに登録された場合、それらのジョブのうち1つだけが開始されます。その他のジョブは、 resource_group が解放されるまで待機します。 リソースグループの動作は、他のプログラミング言語におけるセマフォに似ています。 処理モード を選択することで、デプロイの設定に応じてジョブの並行処理を戦略的に制御できます。デフォルトの処理モードは unordered です。リソースグループの処理モードを変更するには、 API を使用して、既存のリソースグループを編集するリクエストを送信します。 環境ごとに複数のリソースグループを定義できます。たとえば、物理デバイスにデプロイする場合、複数の物理デバイスが存在するかもしれません。各デバイスにデプロイすることは可能ですが、1つのデバイスに対して実行できるデプロイは常に1件だけです。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 英字、数字、 - 、 _ 、 / 、 $ 、 { 、 } 、 . 、およびスペースのみ。 / は先頭にも末尾にも使用できません。CI/CD変数が サポートされています 。 resource_group の例 : この例では、2つの異なるパイプライン内にある2つの deploy-to-production ジョブを同時に実行することは決してできません。これにより、本番環境への同時デプロイが決して発生しないよう制御できます。 クロスプロジェクト/親子パイプラインによるパイプラインレベルの並行処理制御 。 retry を使用して、ジョブが失敗した場合に再試行する回数を設定します。定義されていない場合、デフォルトは 0 になり、ジョブは再試行されません。 ジョブが失敗すると、成功するか最大再試行回数に達するまで、最大であと2回処理が繰り返されます。 デフォルトでは、すべてのタイプの失敗でジョブが再試行されます。再試行の対象となる失敗を選択するには、 retry:when または retry:exit_codes を使用します。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 0 （デフォルト）、 1 、または 2 。 終了コードが 137 の場合、またはRunnerのシステムエラーが発生した場合、 test_advanced は最大2回まで再試行されます。 retry:when は、 retry:max と組み合わせて使用し、失敗の特定のケースでのみジョブを再試行します。 retry:max は、 retry と同様に最大再試行回数であり、指定できる値は 0 、 1 、または 2 です。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 単一の失敗タイプ、または1つ以上の失敗タイプの配列。 always : あらゆる失敗時に再試行します（デフォルト）。 unknown_failure : 失敗の理由が不明な場合に再試行します。 script_failure : 次のいずれかの場合に再試行します。 スクリプトが失敗した。 RunnerがDockerイメージのプルに失敗した。 executor が docker 、 docker+machine 、 kubernetes の場合。 GitLab 19.1で導入され、一部の失敗は script_failure から、より正確な runner_configuration_error に変更されました。 RunnerがDockerイメージのプルに失敗した。 executor が docker 、 docker+machine 、 kubernetes の場合。 GitLab 19.1で導入され、一部の失敗は script_failure から、より正確な runner_configuration_error に変更されました。 api_failure : APIの失敗時に再試行します。 stuck_or_timeout_failure : ジョブがスタックした場合、またはタイムアウトした場合に再試行します。GitLab 19.1で非推奨になりました。 stuck_pending_with_matching_runners 、 stuck_pending_no_matching_runners 、 no_updates_running 、または no_updates_canceling のいずれかで再試行します。代わりにこれらの値を使用してください。 runner_system_failure : Runnerのシステムエラーが発生した場合（ジョブのセットアップの失敗など）に再試行します。 GitLab 19.1で導入され、一部の失敗は runner_system_failure から、より正確な runner_external_dependency_failure または runner_interrupted に変更されました。 GitLab 19.1で導入され、一部の失敗は runner_system_failure から、より正確な runner_external_dependency_failure または runner_interrupted に変更されました。 runner_configuration_error : 無効なイメージまたはタグ、互換性のないプルポリシー、または設定ミスのあるRunnerなど、CI/CDまたはRunnerの設定エラーが原因でジョブが失敗した場合は再試行します。 runner_external_dependency_failure : Runnerが、ネットワークまたはDNSの問題により、イメージレジストリなどの外部依存に到達できなかった場合は再試行します。 runner_interrupted : 再起動、シャットダウン、またはホストの再利用などによって、ジョブの実行中にRunnerが中断された場合は再試行します。 runner_unsupported : Runnerがサポートされていない場合に再試行します。 stale_schedule : 遅延ジョブを実行できなかった場合に再試行します。 job_execution_timeout : ジョブに対して設定されている最大実行時間をスクリプトが超過した場合に再試行します。GitLab 19.1で非推奨になりました。 server_timeout_running または server_timeout_canceling のいずれかで再試行します。代わりにこれらの値を使用してください。 archived_failure : ジョブがアーカイブされていて実行できない場合に再試行します。 unmet_prerequisites : ジョブの前提条件タスクが正常に完了しなかった場合に再試行します。 scheduler_failure : スケジューラーがジョブをRunnerに割り当てられなかった場合に再試行します。 data_integrity_failure : ジョブで不明な問題が発生した場合に再試行します。 retry:when の例 （単一の失敗タイプ）: Runnerのシステムエラー以外の失敗が発生した場合、このジョブは再試行されません。 retry:when の例 （複数の失敗タイプの配列）: retry:exit_codes GitLab 16.10で、 ci_retry_on_exit_codes という 機能フラグ を持つ 導入 されました。デフォルトでは無効になっています。 GitLab 16.11の GitLab.comおよびGitLab Self-Managedで有効 になりました。 GitLab 17.5で 一般提供 になりました。機能フラグ ci_retry_on_exit_codes は削除されました。 retry:exit_codes は、 retry:max と組み合わせて使用し、失敗の特定のケースでのみジョブを再試行します。 retry:max は、 retry と同様に最大再試行回数であり、指定できる値は 0 、 1 、または 2 です。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 retry:exit_codes の例 : 変数を使用して、 ジョブ実行の特定のステージに対する再試行回数 を指定できます。 rules を使用して、パイプラインにジョブを含めたり除外したりすることができます。 パイプラインの作成時にルールが評価され、順番に評価されます。一致するルールが見つかると、それ以降のルールはチェックされず、設定に応じてジョブがパイプラインに含まれるか除外されます。どのルールにも一致しなかった場合、ジョブはパイプラインに追加されません。 rules はルールの配列を受け入れます。各ルールには、少なくとも以下のいずれか1つを含める必要があります。 必要に応じて、以下を組み合わせることもできます。 複数のキーワードを組み合わせて、 複雑なルール を作成することもできます。 ジョブがパイプラインに追加されるのは次の場合です。 if 、 changes 、または exists のルールに一致し、かつ、そのルールが when: on_success （定義されていない場合のデフォルト）、 when: delayed 、または when: always により設定されている場合。 when: on_success 、 when: delayed 、または when: always のみで構成されたルールに到達した場合。 ジョブがパイプラインに追加されないのは次の場合です。 どのルールにも一致しなかった場合。 ルールに一致し、かつ when: never が指定されている場合。 その他の例については、 rules でジョブの実行タイミングを指定する を参照してください。 rules:if 句を使用して、ジョブをパイプラインに追加する条件を指定します。 if ステートメントがtrueの場合、ジョブをパイプラインに追加します。 if ステートメントがtrueでも、 when: never と組み合わされている場合、ジョブをパイプラインに追加しません。 if ステートメントがfalseの場合、次の rules 項目（他に存在する場合）をチェックします。 if 句は次のように評価されます。 CI/CD変数 または 定義済みCI/CD変数 の値に基づいて評価される（ 一部例外 あり）。 rules の実行フロー に従って、順番に評価される。 ジョブ間のルールが矛盾していると、予期せぬ動作につながる可能性がありますが、 workflow ルールはこの問題の軽減に役立ちます。例えば、 重複するパイプライン を引き起こすジョブを誤って設定してしまう可能性があります。 キーワードのタイプ : ジョブ固有およびパイプライン固有。ジョブの一部として使用してジョブの動作を設定するか、または workflow とともに使用してパイプラインの動作を設定できます。 ネストされた変数 を if で使用することはできません。詳細については、 イシュー327780 を参照してください。 ルールが一致し、かつ when が定義されていない場合、ルールはジョブで定義されている when を使用します。ジョブにも定義されていない場合のデフォルトは on_success です。 ジョブレベルの when とルールの when を混在させることができます。 rules の when 設定は、ジョブレベルの when よりも優先されます。 script セクションの変数とは異なり、ルール式内の変数は常に $VARIABLE 形式です。 rules:if と include を組み合わせて使用すると、 他の設定ファイルを条件付きでインクルードできます 。 rules:if と include を組み合わせて使用すると、 他の設定ファイルを条件付きでインクルードできます 。 =~ 式と !~ 式の右辺にあるCI/CD変数は、 正規表現として評価されます 。 rules の一般的な if 式 。 rules を使用してマージリクエストパイプラインを実行する 。 rules:changes を使用して、特定のファイルに対する変更をチェックすることで、ジョブをパイプラインに追加する条件を指定します。 新しいブランチパイプラインの場合、またはGitの push イベントがない場合、 rules: changes は常にtrueと評価され、ジョブは常に実行されます。タグパイプライン、スケジュールされたパイプライン、手動パイプラインなどのパイプラインには、Git push イベントは関連付けられていません。これらのケースに対応するには、 rules: changes: compare_to を使用して、パイプラインのrefと比較するブランチを指定します。 compare_to を使用しない場合、 rules: changes は ブランチパイプライン または マージリクエストパイプライン のみに使用してください。ただし、新しいブランチを作成する際は、 rules: changes は依然としてtrueと評価されます。次のように動作します。 マージリクエストパイプラインでは、 rules:changes は、変更内容をターゲットMRブランチと比較します。 ブランチパイプラインでは、 rules:changes は、変更内容をブランチの直前のコミットと比較します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 次の要素を任意の数だけ含む配列。 ファイルのパス。ファイルのパスには、 CI/CD変数 を含めることができます。 次のようなワイルドカードパス。 単一のディレクトリ（例: path/to/directory/* ）。 ディレクトリとそのすべてのサブディレクトリ（例: path/to/directory/**/* ）。 単一のディレクトリ（例: path/to/directory/* ）。 ディレクトリとそのすべてのサブディレクトリ（例: path/to/directory/**/* ）。 同じ拡張子または複数の拡張子を持つすべてのファイルを対象とするワイルドカード glob パス（例: *.md 、 path/to/directory/*.{rb,py,sh} ）。 ルートディレクトリまたはすべてのディレクトリ内のファイルを対象とするワイルドカードパス（二重引用符で囲む）。例: "*.json" 、 "**/*.json" 。 rules:changes の例 : パイプラインがマージリクエストパイプラインの場合、 Dockerfile と $DOCKERFILES_DIR/**/* 内のファイルに変更がないかどうか確認します。 Dockerfile に変更がある場合、ジョブを手動ジョブとしてパイプラインに追加し、ジョブがトリガーされない場合でもパイプラインの実行を継続します（ allow_failure: true ）。 $DOCKERFILES_DIR/**/* 内のファイルに変更がある場合、ジョブをパイプラインに追加します。 リストされたファイルに変更がなかった場合、いずれのジョブもパイプラインに追加しません（ when: never と同じ）。 globパターンは、Rubyの File.fnmatch で、 フラグ File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB を使用して解釈されます。 パフォーマンス上の理由から、GitLabは changes パターンまたはファイルパスに対して最大50,000回のチェックを実行します。チェック回数が50,000回を超えると、パターンglobを含むルールは常に一致するようになります。つまり、 changes ルールは、50,000を超えるファイルが変更された場合、または変更されたファイルが50,000未満でも changes ルールが50,000回以上チェックされた場合、常に一致することを前提としています。 rules:changes セクションごとに最大50個のパターンまたはファイルパスを定義できます。 一致するファイルのいずれかに変更がある場合、 changes は true に解決されます（ OR 演算）。 その他の例については、 rules でジョブの実行タイミングを指定する を参照してください。 変数とパスの両方に文字 $ を使用できます。たとえば、 $VAR 変数が存在する場合、その値が使用されます。存在しない場合、 $ はパスの一部として解釈されます。 ./ 、二重スラッシュ（ // ）、またはその他の種類の相対パスを使用しないでください。パスは完全な文字列比較で照合され、shellのように評価されません。 rules: changes を使用すると、ジョブまたはパイプラインが予期せず実行される 。 rules:changes を使用して、特定のファイルが変更された場合にのみジョブをパイプラインに追加するよう指定します。また、 rules:changes:paths を使用して、対象とするファイルを指定します。 rules:changes:paths は、 rules:changes をサブキーなしで使用するのと同じです。補足情報と関連トピックもすべて同じです。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 rules:changes と同じです。 rules:changes:paths の例 : この例では、両方のジョブの動作は同じです。 CI/CD変数のサポートは、GitLab 17.2で 導入 されました。 rules:changes:compare_to を使用して、 rules:changes:paths で指定されたファイルに対する変更について比較するrefを指定します。 キーワードのタイプ : ジョブキーワード。これはジョブの一部としてのみ使用でき、 rules:changes:paths と組み合わせる必要があります。 ブランチ名（例: main 、 branch1 、 refs/heads/branch1 ）。 タグ名（例: tag1 、 refs/tags/tag1 ）。 コミットSHA（例: 2fg31ga14b ）。 CI/CD変数が サポートされています 。 rules:changes:compare_to の例 : この例では、 docker build ジョブがパイプラインに含まれるのは、 Dockerfile が refs/heads/branch1 と比較して変更されており、かつパイプラインソースがマージリクエストイベントである場合のみです。 状況によっては compare_to を使用すると、予期しない結果が生じる可能性があります: マージ結果パイプライン では、比較ベースはGitLabが作成する内部コミットであるためです。 フォークしたプロジェクトでは、 イシュー424584 を参照してください。 マージ結果パイプライン では、比較ベースはGitLabが作成する内部コミットであるためです。 フォークしたプロジェクトでは、 イシュー424584 を参照してください。 rules:changes:compare_to を使用すると、 ブランチが空の場合にジョブをスキップ できます。 GitLab 19.2で 導入 されました。 rules:changes:regexp を使用して、globパターンではなくRubyの正規表現を使用して変更されたファイルパスを照合します。 regexp: と paths: は相互に排他的です。 rules:changes ブロックごとに正確に1つを使用します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 Ruby正規表現文字列。最大長は255文字です。このパターンは、変更された各ファイルパスと照合されます。少なくとも1つのパスが一致すれば、ルールは満たされます。 CI/CD変数が サポートされています 。パターン内の変数は、パターンが照合される前に展開されます。255文字の制限は、展開されたパターンにも適用されます。 rules:changes:regexp の例 : この例では、少なくとも1つの変更されたファイルが docs/ ディレクトリの外部にある場合、 backend-tests が実行されます。 アンカーを設定しない限り、このパターンはパスの任意の部分に一致します。完全なパスと一致させるには、パターンを \A と \z でアンカーします。 ^ と $ の代わりに、 \A と \z でパターンをアンカーします。Gitはファイルパス内の改行を許可し、 ^ と $ は改行の境界で一致します。 ^(?!docs/) のようなパターンは、 docs/ の下にあるファイルとその後に続く改行、および別のパスのように、改行を含む細工されたパスに一致する可能性があります。 RE2を使用する rules:if とは異なり、 rules:changes:regexp は Ruby のネイティブ正規表現エンジンを使用します。 先読みと後読みがサポートされています。 ReDoS攻撃を防ぐため、パターンは2つのタイムアウトによって制限されます。各単一パスのマッチには50ミリ秒のタイムアウトがあり、すべてのパスにわたる評価には合計2秒の予算があります。いずれかのタイムアウトを超過した場合、パイプラインは設定エラーで失敗します。 展開されたパターンが255文字より長い場合、パイプラインは設定エラーで失敗します。 パフォーマンス上の理由から、50,000を超えるファイルが変更された場合、ルールはパターンを実行せずに true と評価されます。 regexp: と compare_to: を組み合わせて、比較対象の参照を制御できます。 GitLab 17.7で、 exists パターンまたはファイルパスに対するチェックの最大回数が10,000から50,000に 増加 しました。 ディレクトリパスのサポートは、GitLab 18.2で 導入 されました。 exists を使用して、特定のファイルまたはディレクトリがリポジトリに存在する場合にジョブを実行します。 キーワードのタイプ : ジョブキーワード。ジョブまたは include の一部として使用できます。 ファイルまたはディレクトリパスの配列。パスはプロジェクトディレクトリ（ $CI_PROJECT_DIR ）を基準にした相対パスであり、プロジェクトディレクトリの外部に直接リンクすることはできません。ファイルパスでは、globパターンと CI/CD変数 を使用できます。 rules:exists の例 : job1 は、リポジトリのルートディレクトリに Dockerfile が存在する場合に実行されます。 job2 は、リポジトリ内の任意の場所に Dockerfile が存在する場合に実行されます。 globパターンは、Rubyの File.fnmatch で、 フラグ File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB を使用して解釈されます。 パフォーマンス上の理由から、GitLabは exists パターンまたはファイルパスに対して最大50,000回のチェックを実行します。チェック回数が50,000回を超えると、パターンglobを含むルールは常に一致するようになります。つまり、 exists ルールは、ファイル数が50,000を超えるプロジェクト、またはファイル数が50,000未満でも exists ルールのチェック回数が50,000回を超えるプロジェクトでは、常に一致することを前提としています。 パターンglobが複数ある場合、上限は50,000をglobの数で割った数になります。たとえば、パターンglobが5つあるルールでは、ファイル数の上限は10,000になります。 パターンglobが複数ある場合、上限は50,000をglobの数で割った数になります。たとえば、パターンglobが5つあるルールでは、ファイル数の上限は10,000になります。 rules:exists セクションごとに最大50個のパターンまたはファイルパスを定義できます。 リスト内のいずれかのファイルが見つかった場合、 exists は true に解決されます（ OR 演算）。 ジョブレベルの rules:exists を使用すると、GitLabはパイプラインを実行するプロジェクトとrefでファイルを検索します。 include と rules:exists を組み合わせて 使用すると、GitLabは include セクションを含むファイルのプロジェクトとrefでファイルまたはディレクトリを検索します。以下を使用する場合、 include セクションを含むプロジェクトと、パイプラインを実行するプロジェクトが異なる場合があります。 ネストされたインクルード 。 コンプライアンスパイプライン 。 コンプライアンスパイプライン 。 rules の評価はジョブの実行および アーティファクト のフェッチよりも前に行われるため、 rules:exists はアーティファクトの存在をチェックできません。 ディレクトリの存在をテストするには、パスをフォワードスラッシュ（/）で終わらせる必要があります。 GitLab 16.11で ci_support_rules_exists_paths_and_project 機能フラグ とともに 導入 されました。デフォルトでは無効になっています。 GitLab 17.0で 一般提供 になりました。機能フラグ ci_support_rules_exists_paths_and_project は削除されました。 rules:exists:paths は、 rules:exists をサブキーなしで使用するのと同じです。補足情報もすべて同じです。 キーワードのタイプ : ジョブキーワード。ジョブまたは include の一部として使用できます。 rules:exists:paths の例 : この例では、両方のジョブの動作は同じです。 GitLab 16.11で ci_support_rules_exists_paths_and_project 機能フラグ とともに 導入 されました。デフォルトでは無効になっています。 GitLab 17.0で 一般提供 になりました。機能フラグ ci_support_rules_exists_paths_and_project は削除されました。 rules:exists:project を使用して、 rules:exists:paths のリストに含まれるファイルの検索場所を指定します。 rules:exists:paths と一緒に使用する必要があります。 キーワードのタイプ : ジョブキーワード。ジョブまたは include の一部として使用でき、 rules:exists:paths と組み合わせる必要があります。 exists:project : ネームスペースとグループを含む、プロジェクトのフルパス。 exists:ref : オプション。ファイルの検索に使用するコミットref。refとしては、タグ、ブランチ名、またはSHAを指定できます。指定しない場合、デフォルトはプロジェクトの HEAD です。 rules:exists:project の例 : この例では、 docker build ジョブがパイプラインに含まれるのは、プロジェクト my-group/my-project の v1.0.0 タグが付けられたコミットに Dockerfile が存在する場合のみです。 GitLab 19.2で 導入 されました。 rules:exists:regexp を使用して、globパターンではなくRubyの正規表現を使用してリポジトリ内のファイルパスを照合します。 regexp: と paths: は相互に排他的です。 rules:exists ブロックごとに正確に1つを使用します。 キーワードのタイプ : ジョブキーワード。ジョブまたは include の一部として使用できます。 Ruby正規表現文字列。最大長は255文字です。このパターンは、リポジトリ内のすべてのファイルパスと照合されます。少なくとも1つのパスが一致すれば、ルールは満たされます。 CI/CD変数が サポートされています 。パターン内の変数は、パターンが照合される前に展開されます。255文字の制限は、展開されたパターンにも適用されます。 rules:exists:regexp の例 : この例では、リポジトリ内のどこかに .go ファイルが存在する場合にジョブが実行されます。 アンカーを設定しない限り、このパターンはパスの任意の部分に一致します。完全なパスと一致させるには、パターンを \A と \z でアンカーします。 ^ と $ の代わりに、 \A と \z でパターンをアンカーします。Gitはファイルパス内の改行を許可し、 ^ と $ は改行の境界で一致します。 ^(?!docs/) のようなパターンは、 docs/ の下にあるファイルとその後に続く改行、および別のパスのように、改行を含む細工されたパスに一致する可能性があります。 RE2を使用する rules:if とは異なり、 rules:exists:regexp は Ruby のネイティブ正規表現エンジンを使用します。 先読みと後読みがサポートされています。 ReDoS攻撃を防ぐため、パターンは2つのタイムアウトによって制限されます。各単一パスのマッチには50ミリ秒のタイムアウトがあり、すべてのパスにわたる評価には合計2秒の予算があります。いずれかのタイムアウトを超過した場合、パイプラインは設定エラーで失敗します。 展開されたパターンが255文字より長い場合、パイプラインは設定エラーで失敗します。 パフォーマンス上の理由から、リポジトリに50,000を超えるファイルが含まれている場合、ルールはパターンを実行せずに true と評価されます。 regexp: を project: および ref: と組み合わせて、別のプロジェクトを検索できます。 rules:when を単独で、または別のルールの一部として使用して、ジョブをパイプラインに追加する条件を制御します。 rules:when は when に似ていますが、インプットオプションが若干異なります。 rules:when ルールが if 、 changes 、または exists と組み合わされていない場合、ジョブのルールを評価する際にこのルールに到達すると、常に一致します。 キーワードのタイプ : ジョブ固有。ジョブの一部としてのみ使用できます。 on_success （デフォルト）: 前のステージでジョブが失敗しなかった場合にのみ、ジョブを実行します。 on_failure : 前のステージで少なくとも1つのジョブが失敗した場合にのみ、ジョブを実行します。 never : 前のステージのジョブのステータスに関係なく、ジョブを実行しません。 always : 前のステージのジョブのステータスに関係なく、ジョブを実行します。 manual : ジョブを 手動ジョブ としてパイプラインに追加します。 allow_failure のデフォルト値が false に変わります。 delayed : ジョブを 遅延ジョブ としてパイプラインに追加します。 rules:when の例 : この例では、次の条件で job1 がパイプラインに追加されます。 デフォルトブランチでは、 when が定義されていない場合のデフォルトの動作である when: on_success が適用されます。 フィーチャーブランチでは、遅延ジョブとして追加されます。 それ以外の場合は、手動ジョブとして追加されます。 on_success と on_failure の条件でジョブのステータスを評価する場合: 前のステージで allow_failure: true が設定されているジョブは、失敗しても成功したと見なされます。 前のステージでスキップされたジョブ（ 開始されていない手動ジョブ など）は、成功したと見なされます。 前のステージで allow_failure: true が設定されているジョブは、失敗しても成功したと見なされます。 前のステージでスキップされたジョブ（ 開始されていない手動ジョブ など）は、成功したと見なされます。 rules:when: manual を使用して 手動ジョブを追加 する場合: allow_failure はデフォルトで false になります。このデフォルトは、 when: manual を使用して手動ジョブを追加する場合の動作とは逆になります。 rules の外部で定義された when: manual と同じ動作を実現するには、 rules: allow_failure を true に設定します。 allow_failure はデフォルトで false になります。このデフォルトは、 when: manual を使用して手動ジョブを追加する場合の動作とは逆になります。 rules の外部で定義された when: manual と同じ動作を実現するには、 rules: allow_failure を true に設定します。 rules:allow_failure rules で allow_failure: true を使用して、ジョブが失敗してもパイプラインが停止しないようにします。 allow_failure: true は、手動ジョブでも使用できます。パイプラインは、手動ジョブの結果を待たずに実行を継続します。ルールで allow_failure: false と when: manual を組み合わせると、パイプラインは手動ジョブが実行されるまで待機してから続行します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 true または false 。定義されていない場合のデフォルトは false です。 rules:allow_failure の例 : ルールに一致する場合、ジョブは allow_failure: true が設定された手動ジョブになります。 ルールレベルの rules:allow_failure はジョブレベルの allow_failure をオーバーライドし、特定のルールがジョブをトリガーする場合にのみ適用されます。 ルールで needs を使用して、特定の条件に応じてジョブの needs を更新します。条件がルールに一致すると、ジョブの needs 設定は、ルール内の needs で完全に置き換えられます。 キーワードのタイプ : ジョブ固有。ジョブの一部としてのみ使用できます。 ジョブ名と、必要に応じて追加の属性を含めたハッシュ。 特定の条件が満たされた場合に、ジョブのneedsをnoneに設定するための空の配列（ [] ）。 rules:needs の例 : パイプラインがデフォルトブランチではないブランチで実行され、その結果ルールが最初の条件に一致した場合、 specs ジョブには build-dev ジョブが必要です。 パイプラインがデフォルトブランチで実行され、その結果ルールが2番目の条件に一致した場合、 specs ジョブには build-prod ジョブが必要です。 ルール内の needs は、ジョブレベルで定義されている needs をオーバーライドします。オーバーライドされた場合の動作は、 ジョブレベルの needs と同じです。 ルール内の needs は、 artifacts と optional を受け入れます。 rules:variables rules で variables を使用して、特定の条件に応じて変数を定義します。 キーワードのタイプ : ジョブ固有。ジョブの一部としてのみ使用できます。 VARIABLE-NAME: value 形式の変数のハッシュ。 rules:variables の例 : rules:interruptible ルールで interruptible を使用して、特定の条件に応じてジョブの interruptible 値を更新します。 キーワードのタイプ : ジョブ固有。ジョブの一部としてのみ使用できます。 true または false 。 rules:interruptible の例 : ルールレベルの rules:interruptible はジョブレベルの interruptible をオーバーライドし、特定のルールがジョブをトリガーする場合にのみ適用されます。 GitLab 17.3で、 pipeline_run_keyword という 機能フラグ を持つ 導入 されました。デフォルトでは無効になっています。GitLab Runner 17.1が必要です。 機能フラグ pipeline_run_keyword は、GitLab 17.5で 削除 されました。 この機能はテスト可能ですが、本番環境での使用には適していません。 run を使用して、ジョブ内で実行する一連の ステップ を定義します。各ステップは、スクリプトまたは定義済みステップのいずれかになります。 オプションで環境変数とインプットを指定することもできます。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 ハッシュの配列。各ハッシュは次のキーを指定したステップを表します。 name : ステップの名前を表す文字列。 script : 実行するShellコマンドを含む文字列。 step : 実行する定義済みステップを識別する文字列。 env : オプション。このステップに固有の環境変数のハッシュ。 inputs : オプション。定義済みステップの入力パラメータのハッシュ。 name : ステップの名前を表す文字列。 script : 実行するShellコマンドを含む文字列。 step : 実行する定義済みステップを識別する文字列。 env : オプション。このステップに固有の環境変数のハッシュ。 inputs : オプション。定義済みステップの入力パラメータのハッシュ。 各配列のエントリに name は必須であり、 script または step のいずれか一方（両方は不可）を指定する必要があります。 この例では、ジョブには次の2つのステップがあります。 hello_steps が、Shellコマンド echo を実行します。 bye_steps が、環境変数とインプットパラメータを指定した定義済みステップを使用します。 ステップには script か step キーのいずれか一方を指定できます。両方を指定することはできません。 run の設定を、既存のキーワード script 、 after_script 、 before_script と一緒に使用することはできません。 複数行のスクリプトは、 YAMLブロックスカラー構文 を使用して定義できます。 script を使用して、Runnerが実行するコマンドを指定します。 トリガージョブ を除くすべてのジョブでは、 script キーワードが必須です。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 次の内容を含む配列。 複数行に分割された 長いコマンド。 CI/CD変数が サポートされています 。 script 内で特殊文字 を使用する場合は、単一引用符（ ' ）または二重引用符（ " ）を使用する必要があります。 ゼロ以外の終了コードを無視 できます。 script でカラーコードを使用する と、ジョブログのレビューが容易になります。 カスタムの折りたたみ可能なセクションを作成 して、ジョブログ出力をシンプルにできます。 プラン : Premium、Ultimate 提供形態 : GitLab.com、GitLab Self-Managed、GitLab Dedicated secrets を使用して、次のような CI/CDシークレット を指定します。 外部シークレットプロバイダーから取得する。 ジョブ内で CI/CD変数 として使用できるようにする（デフォルトでは file タイプ ）。 secrets:vault を使用して、 HashiCorp Vault によって提供されるシークレットを指定します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 engine:name : シークレットエンジンの名前。 kv-v2 （デフォルト）、 kv-v1 、または generic のいずれか。 engine:path : シークレットエンジンのパス。 path : シークレットのパス。 field : パスワードが格納されているフィールドの名前。 secrets:vault の例 : すべての詳細を明示的に指定し、 KV-V2 シークレットエンジンを使用するには、次のようにします。 この構文は短縮できます。短縮構文では、 engine:name と engine:path がどちらもデフォルトで kv-v2 になります。 短縮構文でカスタムシークレットエンジンのパスを指定するには、 @ で始まるサフィックスを追加します。 secrets:gcp_secret_manager secrets:gcp_secret_manager を使用して、 GCP Secret Manager によって提供されるシークレットを指定します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 name : シークレットの名前。 version : シークレットのバージョン。 secrets:gcp_secret_manager の例 : GitLab CI/CDでGCP Secret Managerシークレットを使用する 。 secrets:gitlab_secrets_manager GitLab 19.0で 導入 されました。GitLab Runner 19.0以降が必要です。 GitLab Secrets Manager からシークレットを指定するには、 secrets:gitlab_secrets_manager を使用します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 name : シークレットの名前。 source : オプション。シークレットのソース。指定しない場合、現在のプロジェクトにデフォルト設定されます。グループシークレットには group/<full-path-to-group> を使用します。 secrets:gitlab_secrets_manager の例 : secrets:azure_key_vault secrets:azure_key_vault を使用して、 Azure Key Vault によって提供されるシークレットを指定します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 name : シークレットの名前。 version : シークレットのバージョン。 secrets:azure_key_vault の例 : GitLab CI/CDでAzure Key Vaultシークレットを使用する 。 secrets:file を使用して、シークレットを file または variable タイプのCI/CD変数 として格納するよう設定します。 デフォルトでは、シークレットは file タイプのCI/CD変数としてジョブに渡されます。シークレットの値がファイルに保存され、変数にはそのファイルのパスが格納されます。 ソフトウェアで file タイプのCI/CD変数を使用できない場合は、 file: false を設定して、シークレットの値を変数に直接保存してください。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 true （デフォルト）または false 。 secrets:file の例 : file キーワードはCI/CD変数の設定であり、 vault セクションではなくCI/CD変数名の下にネストする必要があります。 secrets:token を使用して、トークンのCI/CD変数を参照することにより、外部シークレットプロバイダーで認証する際に使用するトークンを明示的に選択します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 secrets:token の例 : token キーワードが設定されておらず、トークンが1つしか定義されていない場合、定義されたトークンが自動的に使用されます。 複数のトークンが定義されている場合は、 token キーワードを設定して、使用するトークンを指定する必要があります。使用するトークンを指定しない場合、ジョブの実行ごとにどのトークンが使用されるかを予測することはできません。 services を使用して、スクリプトの正常な実行に必要な追加のDockerイメージを指定します。 services イメージ は、 image キーワードで指定されたイメージにリンクされます。 ジョブの設定とデフォルト設定は一緒にマージされません。パイプラインに default:services が定義されていて、ジョブにも services がある場合、ジョブの設定が優先され、デフォルト設定は使用されません。 サービス間ネットワーキングを有効にするには、 FF_NETWORK_PER_BUILD を true に設定します。このフラグがないと、サービスが正常に動作しない可能性があります。詳細については、 feature flags を参照してください。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 サポートされている値 : サービスイメージの名前（必要に応じてレジストリパスを含む）。次のいずれかの形式で指定します。 <image-name> （ <image-name> に latest タグを付けた場合と同じ） <image-name>:<tag> <image-name>@<digest> CI/CD変数は サポートされています が、 alias にはサポートされていません。 alias を動的にカスタマイズするには、代わりに CI/CDインプット を使用します。 この例では、GitLabはジョブ用に以下の2つのコンテナを起動します。 script コマンドを実行するRubyコンテナ。 PostgreSQLコンテナ。Rubyコンテナの script コマンドは、ホスト名に db-postgres を指定してPostgreSQLデータベースに接続できます。 トップレベルで services を使用しても、 default セクションでは使用しない場合、 非推奨 になります。 services で使用可能な設定 。 .gitlab-ci.yml ファイルで services を定義する 。 DockerコンテナでCI/CDジョブを実行する 。 Dockerを使用してDockerイメージをビルドする 。 サービスに使用するイメージの完全名。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 サポートされている値 : サービスイメージの名前（必要に応じてレジストリパスを含む）。次のいずれかの形式で指定します。 <image-name> （ <image-name> に latest タグを付けた場合と同じ） <image-name>:<tag> <image-name>@<digest> CI/CD変数が サポートされています 。 services:name の例 : 複数の同一のサービスイメージを使用する場合、またはサービスイメージ名が長い場合は、 alias を使用して一意の名前エイリアスを定義します。 entrypoint 、 command 、 variables などの他のサービスオプションで使用する場合、 name キーワードが必要です。 詳細については、 サービスにアクセスする を参照してください。 GitLab Runner 17.9で 導入 されました。 ジョブのコンテナからサービスにアクセスするための追加エイリアス。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 サポートされている値 : スペースまたはコンマで区切られた1つ以上のエイリアスを含む文字列。 services:alias の例 : 複数のエイリアスは、スペースまたはカンマで区切って指定できます。 詳細については、 サービスにアクセスする および Kubernetes executorのサービスコンテナ名としてエイリアスを使用する を参照してください。 services:docker services:docker を使用して、GitLab RunnerのDocker executorにオプションを渡します。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 Docker executorのオプションを定義するハッシュ。以下を含めることができます。 platform : プルするイメージのアーキテクチャを選択します。指定しない場合、デフォルトはホストRunnerと同じプラットフォームです。 user : コンテナの実行時に使用するユーザー名またはUIDを指定します。 services:docker の例 : services:docker:platform は、 docker pull --platform オプション にマップされます。 services:docker:user は、 docker run --user オプション にマップされます。 services:kubernetes GitLab 18.0で 導入 されました。GitLab Runner 17.11以降が必要です。 user インプットオプションは、GitLab Runner 17.11で 導入 されました。 user インプットオプションは、GitLab 18.0で uid:gid 形式をサポートするように拡張 されました。 services:kubernetes を使用して、GitLab Runner Kubernetes executor にオプションを渡します。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 Kubernetes executorのオプションを定義するハッシュ。以下を含めることができます。 user : コンテナの実行時に使用するユーザー名またはUIDを指定します。 UID:GID 形式を使用して、GIDを設定することもできます。 UIDのみを使用した services:kubernetes の例 : UIDとGIDの両方を使用した services:kubernetes の例 : services:entrypoint コンテナのエントリポイントとして実行するコマンドまたはスクリプト。 Dockerコンテナの作成時に、 entrypoint はDockerの --entrypoint オプションに変換されます。構文は Dockerfileの ENTRYPOINT ディレクティブ に似ており、各Shellトークンは配列内の個別の文字列です。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 サポートされている値 : エントリポイントコマンドを表す文字列の配列。 services:entrypoint の例 : services:command コンテナのコマンドとして使用されるコマンドまたはスクリプト。 イメージ名の後に続く引数として解釈され、Dockerに渡されます。構文は Dockerfile CMD ディレクティブに似ており、各シェルトークンは配列内の個別の文字列です。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 サポートされている値 : コマンドを表す文字列の配列。 services:command の例 : services:variables サービスのみに渡される追加の環境変数。サービス変数は、サービスコンテナにのみ渡され、ジョブコンテナでは使用できません。 構文は ジョブ変数 と同じです。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 サポートされている値 : 環境変数名と値のハッシュ。 services:variables の例 : サービス変数はそれ自体を参照できず、変数の展開または補間をサポートしていません。 ジョブまたはパイプラインレベルで定義された変数は、自動的にサービスに渡されます。詳細については、 CI/CD変数をサービスに渡す を参照してください。 サービス変数は、定義されている特定のサービスでのみ使用できます。 services:pull_policy RunnerがDockerイメージをフェッチするために使用するプルポリシー。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 1つのプルポリシー、または配列で指定する複数のプルポリシー。 always 、 if-not-present 、 never のいずれかを指定できます。 services:pull_policy の例 : 定義済みのプルポリシーをRunnerがサポートしていない場合、ジョブは次のようなエラーで失敗します: ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never]) 。 DockerコンテナでCI/CDジョブを実行する 。 Runnerがイメージをプルする方法を設定する 。 複数のプルポリシーを設定する 。 stage を使用して、ジョブを実行する ステージ を定義します。同じ stage 内のジョブは、並列実行できます（ 補足情報 を参照）。 stage が定義されていない場合、ジョブはデフォルトで test ステージを使用します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 次のいずれかの文字列: ステージ名は255文字以下でなければなりません。 ジョブが異なる複数のRunnerで実行される場合、並列実行が可能です。 Runnerが1つしかない場合でも、そのRunnerの concurrent 設定 が 1 より大きければ、ジョブを並列実行できます。 .pre ステージを使用して、パイプラインの開始時にジョブを実行します。デフォルトでは、 .pre はパイプラインの最初のステージです。ユーザー定義ステージは、 .pre の後に実行されます。 stages 内で .pre を定義する必要はありません。 パイプラインに .pre ステージまたは .post ステージのジョブしか含まれていない場合、そのパイプラインは実行されません。これら以外のステージに少なくとも1つのジョブが必要です。 キーワードのタイプ : ジョブの stage キーワードと組み合わせる場合にのみ使用できます。 stage: .pre の例 : パイプラインに needs: [] を指定したジョブと .pre ステージのジョブがある場合、それらはすべてパイプラインの作成直後に開始されます。 needs: [] を指定したジョブは、ステージ設定を無視してすぐに開始されます。 パイプライン実行ポリシー で、 .pre の前に実行される .pipeline-policy-pre ステージを定義できます。 .post ステージを使用して、パイプラインの最後にジョブを実行します。デフォルトでは、 .post はパイプラインの最後のステージです。ユーザー定義ステージは、 .post の前に実行されます。 stages 内で .post を定義する必要はありません。 パイプラインに .pre ステージまたは .post ステージのジョブしか含まれていない場合、そのパイプラインは実行されません。これら以外のステージに少なくとも1つのジョブが必要です。 キーワードのタイプ : ジョブの stage キーワードと組み合わせる場合にのみ使用できます。 stage: .post の例 : パイプライン実行ポリシー で、 .post の後に実行される .pipeline-policy-post ステージを定義できます。 tags を使用して、プロジェクトで使用可能なすべてのRunnerのリストから特定のRunnerを選択します。 Runnerを登録する際に、Runnerのタグ（ ruby 、 postgres 、 development など）を指定できます。ジョブを取得して実行するには、ジョブにリストされているすべてのタグがRunnerに割り当てられている必要があります。 ジョブの設定とデフォルト設定は一緒にマージされません。パイプラインに default:tags が定義されていて、ジョブにも tags がある場合、ジョブの設定が優先され、デフォルト設定は使用されません。 キーワードのタイプ : ジョブキーワード。ジョブの一部として、または default セクション でのみ使用できます。 タグ名の配列（大文字と小文字が区別されます）。 CI/CD変数が サポートされています 。 この例では、ジョブを実行できるのは、 ruby タグと postgres タグの両方が指定されたRunnerのみです。 タグの数は 50 未満でなければなりません。 タグを使用してRunnerが実行できるジョブを制御する 並列マトリックスジョブごとに異なるRunnerタグを選択する ホストRunnerのRunnerタグ: Linux上のホストRunner GPU対応のホストRunner macOS上のホストRunner Windows上のホストRunner Linux上のホストRunner GPU対応のホストRunner macOS上のホストRunner Windows上のホストRunner timeout を使用して、特定のジョブのタイムアウトを設定します。ジョブがタイムアウトより長く実行されると、ジョブは失敗します。 ジョブレベルのタイムアウトは、 プロジェクトレベルのタイムアウト よりも長くすることができますが、 Runnerのタイムアウト よりも長くすることはできません。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 サポートされている値 : 自然言語で記述された期間。たとえば、以下の表記はすべて同等です。 timeout キーワードは default 設定ではサポートされていません。代わりに個々のジョブ設定で timeout を定義します。詳細については、 イシュー213634 を参照してください。 trigger を使用して、ジョブが次のいずれかの ダウンストリームパイプライン を開始する「トリガージョブ」であることを宣言します。 マルチプロジェクトパイプライン 。 トリガージョブで使用できるGitLab CI/CD設定キーワードは限られています。トリガージョブで使用できるキーワードは次のとおりです。 allow_failure 。 needs 。ただし、 needs:project は除きます。 only と except 。 when （ on_success 、 on_failure 、 always 、または manual の値の場合のみ）。 resource_group 。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 マルチプロジェクトパイプラインの場合、ダウンストリームプロジェクトのパス。CI/CD変数は サポートされています が、 ジョブ 専用変数はサポートされていません。または、 trigger:project を使用することもできます。 子パイプラインの場合は、 trigger:include を使用します。 trigger と同じジョブで when:manual を使用できますが、APIを使用して when:manual のトリガージョブを開始することはできません。詳細については、 イシュー284086 を参照してください。 手動トリガージョブを実行する前に、 CI/CD変数を手動で指定 することはできません。 トップレベルの variables セクション（グローバル）またはトリガージョブ内で定義された CI/CD変数 は、 トリガー変数 としてダウンストリームパイプラインに転送されます。 パイプライン変数 は、デフォルトではダウンストリームパイプラインに渡されません。これらの変数をダウンストリームパイプラインに転送するには、 trigger:forward を使用します。 ジョブ専用変数 は、トリガージョブでは使用できません。 Runnerの config.toml で定義された 環境変数は、トリガージョブでは使用できず、ダウンストリームパイプラインに渡されません。 トリガージョブでは needs:pipeline:job を使用できません。 マルチプロジェクトパイプライン設定の例 。 特定のブランチ、タグ、またはコミットのパイプラインを実行するには、 トリガートークン を使用して パイプライントリガーAPI に対して認証を行えます。トリガートークンは、 trigger キーワードとは異なります。 GitLab 17.11で 導入 されました。 ダウンストリームパイプライン設定で spec:inputs を使用している場合、 trigger:inputs を使用して、マルチプロジェクトパイプラインの インプット を設定します。 trigger:inputs の例 : trigger:include trigger:include を使用して、ジョブが 子パイプライン を開始する「トリガージョブ」であることを宣言します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 子パイプラインの設定ファイルのパス。 trigger:include の例 : trigger:include:artifact を使用して、 動的子パイプライン をトリガーします。 trigger:include:artifact を使用して、 動的子パイプライン をトリガーします。 ダウンストリームパイプライン設定で spec:inputs を使用している場合、 trigger:include:inputs を使用して インプット を設定します。 ダウンストリームパイプライン設定で spec:inputs を使用している場合、 trigger:include:inputs を使用して インプット を設定します。 以下の場合、子パイプラインの設定ファイルへのパスとして trigger:include:local を使用します: 複数の子パイプライン設定ファイル を結合する。 trigger:include:inputs と結合して、インプットを子パイプラインに渡す。例: staging-job : trigger : include : - local : path/to/child-pipeline.yml inputs : environment : staging 以下の場合、子パイプラインの設定ファイルへのパスとして trigger:include:local を使用します: 複数の子パイプライン設定ファイル を結合する。 複数の子パイプライン設定ファイル を結合する。 trigger:include:inputs と結合して、インプットを子パイプラインに渡す。例: staging-job : trigger : include : - local : path/to/child-pipeline.yml inputs : environment : staging trigger:include:inputs と結合して、インプットを子パイプラインに渡す。例: trigger:include:project を使用して、 別のプロジェクト内の構成ファイルを使用して 子パイプラインをトリガーします。ファイルに他の include エントリが含まれている場合、GitLabはファイルをホストしているプロジェクトではなく、パイプラインを実行しているプロジェクト内のファイルを検索します。 trigger:include:project を使用して、 別のプロジェクト内の構成ファイルを使用して 子パイプラインをトリガーします。ファイルに他の include エントリが含まれている場合、GitLabはファイルをホストしているプロジェクトではなく、パイプラインを実行しているプロジェクト内のファイルを検索します。 trigger:include:template を使用して、CI/CDテンプレートで子パイプラインをトリガーします。 trigger:include:template を使用して、CI/CDテンプレートで子パイプラインをトリガーします。 trigger:include:inputs GitLab 17.11で 導入 されました。 ダウンストリームパイプライン設定で spec:inputs を使用している場合、 trigger:include:inputs を使用して、子パイプラインの インプット を設定します。 trigger:inputs の例 : trigger:project trigger:project を使用して、ジョブが マルチプロジェクトパイプライン を開始する「トリガージョブ」であることを宣言します。 デフォルトでは、マルチプロジェクトパイプラインはデフォルトブランチに対してトリガーされます。別のブランチを指定するには、 trigger:branch を使用します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 ダウンストリームプロジェクトのパス。CI/CD変数は サポートされています が、 ジョブ 専用変数はサポートされていません。 trigger:project の例 : 別のブランチに対する trigger:project の例 : マルチプロジェクトパイプライン設定の例 。 特定のブランチ、タグ、またはコミットのパイプラインを実行するには、 トリガートークン を使用して パイプライントリガーAPI に対して認証することもできます。トリガートークンは、 trigger キーワードとは異なります。 trigger:strategy strategy:mirror オプションは、GitLab 18.2で 導入 されました。 trigger:strategy を使用して、ダウンストリームパイプラインが完了するまでは trigger ジョブが 成功 とマークされないように制御します。 この動作はデフォルトとは異なります。デフォルトでは、ダウンストリームパイプラインが作成されるとすぐに、 trigger ジョブは 成功 とマークされます。 この設定により、パイプラインは並列ではなく直列で実行されます。 mirror : ダウンストリームパイプラインのステータスを正確にミラーリングします。 depend : 推奨されません。代わりに mirror を使用してください。トリガージョブのステータスは、ダウンストリームパイプラインのステータスに応じて、 失敗 、 成功 、または 実行中 と表示されます。補足情報を参照してください。 trigger:strategy の例 : この例では、後続ステージのジョブは、トリガーされたパイプラインが正常に完了するまで開始されません。 ダウンストリームパイプラインの オプションの手動ジョブ は、ダウンストリームパイプラインまたはアップストリームのトリガージョブのステータスに影響を与えません。ダウンストリームパイプラインは、オプションの手動ジョブを実行しなくても正常に完了できます。 デフォルトでは、後続ステージのジョブは、トリガージョブが完了するまで開始されません。 ダウンストリームパイプラインの ブロック手動ジョブ は、トリガージョブが成功または失敗としてマークされる前に実行する必要があります。 strategy:depend を使用する場合（推奨されていません。代わりに strategy:mirror を使用してください）: 手動ジョブが原因でダウンストリームパイプラインのステータスが 手動アクション待ち （ ）になっている場合、トリガージョブは 実行中 （ ）と表示されます。 ダウンストリームパイプラインに失敗したジョブがあっても、そのジョブで allow_failure: true を使用している場合、ダウンストリームパイプラインは成功と見なされ、トリガージョブは 成功 と表示されます。 手動ジョブが原因でダウンストリームパイプラインのステータスが 手動アクション待ち （ ）になっている場合、トリガージョブは 実行中 （ ）と表示されます。 ダウンストリームパイプラインに失敗したジョブがあっても、そのジョブで allow_failure: true を使用している場合、ダウンストリームパイプラインは成功と見なされ、トリガージョブは 成功 と表示されます。 trigger:forward trigger:forward を使用して、ダウンストリームパイプラインに転送する内容を指定します。 親子パイプライン と マルチプロジェクトパイプライン の両方に転送する内容を制御できます。 デフォルトでは、ネストされたダウンストリームパイプラインでは、転送された変数が再度転送されることはありません。再度転送するには、ネストされたダウンストリームのトリガージョブでも trigger:forward を使用する必要があります。 yaml_variables : true （デフォルト）、または false 。 true の場合、トリガージョブで定義されている変数がダウンストリームパイプラインに渡されます。 pipeline_variables : true または false （デフォルト）。 true の場合、 パイプライン変数 がダウンストリームパイプラインに渡されます。 trigger:forward の例 : CI/CD変数 MYVAR = my value を指定して、 このパイプラインを手動で実行 します。 trigger:forward でダウンストリームパイプラインに転送されるCI/CD変数は、優先順位の高い パイプライン変数 です。ダウンストリームパイプラインで同じ名前の変数が定義されている場合、その変数は通常、転送された変数によって上書きされます。 when を使用して、ジョブの実行条件を設定します。ジョブで定義されていない場合、デフォルト値は when: on_success です。 キーワードのタイプ : ジョブキーワード。ジョブの一部として使用できます。 when: always と when: never は、 workflow:rules でも使用できます。 on_success （デフォルト）: 前のステージでジョブが失敗しなかった場合にのみ、ジョブを実行します。 on_failure : 前のステージで少なくとも1つのジョブが失敗した場合にのみ、ジョブを実行します。 never : 前のステージのジョブのステータスに関係なく、ジョブを実行しません。 rules セクションまたは workflow: rules でのみ使用できます。 always : 前のステージのジョブのステータスに関係なく、ジョブを実行します。 manual : ジョブを 手動ジョブ としてパイプラインに追加します。 delayed : ジョブを 遅延ジョブ としてパイプラインに追加します。 この例では、スクリプトは次のように動作します。 build_job が失敗した場合にのみ、 cleanup_build_job を実行します。 成功か失敗かに関係なく、常にパイプラインの最後のステップとして cleanup_job を実行します。 GitLab UIで手動で実行した場合、 deploy_job を実行します。 on_success と on_failure の条件でジョブのステータスを評価する場合: 前のステージで allow_failure: true が設定されているジョブは、失敗しても成功したと見なされます。 前のステージでスキップされたジョブ（ 開始されていない手動ジョブ など）は、成功したと見なされます。 前のステージで allow_failure: true が設定されているジョブは、失敗しても成功したと見なされます。 前のステージでスキップされたジョブ（ 開始されていない手動ジョブ など）は、成功したと見なされます。 when: manual の場合、 allow_failure のデフォルト値は true です。 rules:when: manual の場合、デフォルト値は false に変わります。 when を rules と組み合わせて使用すると、さらに動的にジョブを制御できます。 when を workflow と組み合わせて使用すると、パイプラインの開始条件を制御できます。 manual_confirmation GitLab 17.1で 導入 されました。 環境停止ジョブのサポートは、GitLab 18.3で 導入 されました。 manual_confirmation と when: manual を組み合わせて使用し、手動ジョブのカスタム確認メッセージを定義します。 when: manual を使用する手動ジョブが定義されていない場合、このキーワードは効果がありません。 手動確認は、 environment:action: stop を使用する環境停止ジョブを含む、すべての手動ジョブで機能します。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 manual_confirmation の例 : start_in を使用して、ジョブの作成後、指定された期間、ジョブの実行を遅らせます。ジョブに when: delayed を設定する必要があります。 キーワードのタイプ : ジョブキーワード。ジョブの一部としてのみ使用できます。 可能なインプット : 秒、分、または時間単位の時間。1週間以下である必要があります。有効な値の例: この例では、 deploy_production ジョブは、前のステージが完了してから30分後に開始されます。 タイマーが開始するのは、前のジョブが終了したときではなく、ジョブのステージが開始されたときです。 遅延ジョブを手動ですぐに開始するには、パイプラインビューで 再生 （ ）を選択します。 最小遅延期間は1秒、最大遅延期間は1週間です。 start_in は、 when が delayed に設定されている場合にのみ機能します。 when に他の値を使用すると、設定が無効になります。ジョブが rules を使用している場合、 start_in および when は、ジョブレベルではなく、 rules で定義する必要があります。そうでない場合は、検証エラー（ config key may not be used with 'rules': start_in ）が表示されます。 start_in は workflow:rules ではサポートされていませんが、構文違反は発生しません。 variables を使用して、 CI/CD変数 を定義します。 変数は、 CI/CDジョブ内で定義する か、またはすべてのジョブに対する デフォルトCI/CD変数 を定義するトップレベル（グローバル）キーワードとして定義できます。 YAMLで定義されたすべての変数は、リンクされている Dockerサービスコンテナ にも設定されます。 YAMLで定義された変数は、機密性の低いプロジェクトの設定を目的としています。機密情報は、 保護された変数 または CI/CDシークレット に保存してください。 手動パイプライン変数 と スケジュールされたパイプライン変数 は、デフォルトではダウンストリームパイプラインに渡されません。これらの変数をダウンストリームパイプラインに転送するには、 trigger:forward を使用します。 定義済み変数 は、Runnerが自動的に作成し、ジョブで使用できるようにする変数です。 変数でRunnerの動作を設定 できます。 ジョブ変数は、ジョブの script 、 before_script 、 after_script セクション内のコマンド、および一部の ジョブキーワード で使用できます。各ジョブキーワードが変数をサポートしているかについては、それぞれの サポートされている値 セクションを確認してください。 ジョブ変数を、 include などの グローバルキーワード の値として使用することはできません。 サポートされている値 : 変数名と値のペア: 名前には数字、英字、アンダースコア（ _ ）のみを使用できます。一部のShellでは、最初の文字が英字でなければなりません。 値は文字列でなければなりません。 CI/CD変数が サポートされています 。 ジョブ variables の例 : review_job では、 DEPLOY_SITE と REVIEW_PATH のジョブ変数が定義されています。これらのジョブ変数は、どちらも script セクションで使用できます。 デフォルト variables トップレベルの variables セクションで定義されている変数は、すべてのジョブに対するデフォルト変数として機能します。 各デフォルト変数は、パイプライン内のあらゆるジョブで使用できます。ただし、ジョブで同じ名前の変数がすでに定義されている場合を除きます。ジョブ内で定義された変数が 優先される ため、同じ名前のデフォルト変数の値はジョブ内で使用できません。 ジョブ変数と同様に、 include などの他のグローバルキーワードの値としてデフォルト変数を使用することはできません。 サポートされている値 : 変数名と値のペア: 名前には数字、英字、アンダースコア（ _ ）のみを使用できます。一部のShellでは、最初の文字が英字でなければなりません。 値は文字列でなければなりません。 CI/CD変数が サポートされています 。 deploy_job には変数が定義されていません。デフォルトの DEPLOY_SITE 変数がジョブにコピーされ、それを script セクションで使用できます。 deploy_review_job にはすでに DEPLOY_SITE 変数が定義されているため、デフォルトの DEPLOY_SITE はジョブにコピーされません。このジョブには、 REVIEW_PATH ジョブ変数も定義されています。これらのジョブ変数は、どちらも script セクションで使用できます。 variables:description description キーワードを使用して、デフォルト変数の説明を定義します。この説明は、 パイプラインを手動で実行する際に、事前に入力された変数名 とともに表示されます。 キーワードのタイプ : このキーワードはデフォルト variables でのみ使用可能です。ジョブ variables では使用できません。 文字列。Markdownを使用できます。 variables:description の例 : value を指定せずに使用した場合、手動でトリガーされなかったパイプラインに変数が存在し、そのデフォルト値は空文字列（ '' ）になります。 variables:value value キーワードを使用して、パイプラインレベル（デフォルト）の変数の値を定義します。 variables: description と組み合わせて使用すると、変数の値は、 パイプラインを手動で実行したときに事前に入力されます 。 キーワードのタイプ : このキーワードはデフォルト variables でのみ使用可能です。ジョブ variables では使用できません。 variables:value の例 : variables: description なしで使用した場合、 variables と同じ動作になります。 variables:options variables:options を使用して、 パイプラインを手動で実行する際にUIで選択できる 値の配列を定義します。 variables: value と組み合わせて使用する必要があります。 value に指定する文字列の条件は次のとおりです。 options 配列内の文字列のいずれかを指定する必要があります。 デフォルトの選択肢として使用されます。 description がない場合、このキーワードは効果がありません。 キーワードのタイプ : このキーワードはデフォルト variables でのみ使用可能です。ジョブ variables では使用できません。 variables:options の例 : variables:expand expand キーワードを使用して、変数を展開可能にするかどうかを設定します。 キーワードのタイプ : このキーワードは、デフォルトとジョブの両方の variables で使用できます。 true （デフォルト）: 変数は展開可能です。 false : 変数は展開できません。 variables:expand の例 : VAR2 の結果は value2 value1 です。 VAR3 の結果は value3 $VAR1 です。 expand キーワードは、デフォルトおよびジョブ variables キーワードでのみ使用できます。 rules:variables や workflow:rules:variables では使用できません。