GitLab CI/CDの環境変数

環境変数は、オペレーティングシステム上で実行中のプロセスの動作に影響を与えることができる、動的に命名された値です。

環境変数は、プロセスの実行環境の一部です。 例えば、実行中のプロセスは、TEMP環境変数の値を照会して、一時ファイルを格納する適切な場所を発見したり、異なるスクリプトで再利用できるデータベース用のURLを定義したりすることができます。

変数はGitLab CI/CDのジョブをカスタマイズするのに便利です。変数を使うと、値をハードコードする必要がありません。

GitLab CI/CDの高度な使い方については、こちらをご覧ください。

事前定義された環境変数

GitLab CI/CDにはデフォルトで定義済みの変数があり、追加指定なしで使用できます。 イシュー番号、ユーザー名、ブランチ名、パイプラインやコミットのIDなどを呼び出すことができます。

Runnerのローカル環境のために、あらかじめ定義された環境変数がGitLabによって提供されます。

GitLab は.gitlab-ci.ymlファイルを読み込んで Runner に情報を送り、そこで変数が展開されます。 Runner はそれからスクリプトコマンドを走らせます。

事前定義された環境変数を使用する

Runnerから出力される既存の定義済み変数の中から1つを選択することができます。

この例では、定義済み変数CI_JOB_STAGEを使用して、ジョブのステージを出力する方法を説明します。

.gitlab-ci.ymlファイルの中で、スクリプトからこの変数を呼び出します。 正しい構文を使用していることを確認してください。 

test_variable:
  stage: test
  script:
    - echo $CI_JOB_STAGE

この場合、Runnerはtestというジョブのtest_variableのステージを出力します。

Output `$CI_JOB_STAGE`

別の例として、独自の GitLab インスタンスを使用していて、GitLab Pagesがどのドメインで提供されているかを知りたいとしましょう。 スクリプト内で定義済みの変数$CI_PAGES_DOMAINを使用すれば、それを呼び出すことができます。 

pages:
  script:
    - ...
    - echo $CI_PAGES_DOMAIN

GitLab.com のユーザーの場合はgitlab.ioが出力されます。プライベートインスタンスの場合は、システム管理者が定義したとおりの出力になります。

カスタム環境変数

特定のカスタム環境変数が必要な場合は、UIやAPI、あるいは.gitlab-ci.ymlファイルで直接設定することが可能です。

この変数は、パイプラインが実行されるたびにRunnerによって使用されます。 また、特定のパイプラインに対して手動で変数値をオーバーライドすることもできます。

変数には、Variableと Fileの2種類があります。.gitlab-ci.ymlファイルでは型を設定できませんが、UIやAPIで設定することが可能です。

.gitlab-ci.ymlにカスタム変数を作成します

カスタムenv_var変数を作成するために .gitlab-ci.ymlファイルで変数と値のペアを定義します。 

variables:
  TEST: "HELLO WORLD"

そして、その値をスクリプトで呼び出すことができます。 

  script:
    - echo "$TEST"

詳しくは、.gitlab-ci.yml定義変数をご覧ください。

UIでカスタム変数を作成する

UI内から、カスタム環境変数の追加や更新を行うことができます。

  1. プロジェクトの設定→CI/CDで、変数セクションを展開します。

  2. 変数の追加ボタンをクリックします。変数の追加モーダルで、詳細を入力します。

    • Key：1行で、スペースを入れず、文字、数字、_のみ使用すること。
    • Value：制限なし。
    • Type：FileまたはVariable。
    • 環境範囲：すべて、または特定の環境。
    • 変数の保護（オプション）：選択すると、保護ブランチまたはタグで実行されるパイプラインでのみ変数が利用可能になります。
    • 変数のマスク（オプション）：選択した場合、変数の値はジョブログでマスクされます。 値がマスクの要件を満たしていない場合、変数は保存に失敗します。

変数の作成後、 編集ボタンをクリックすると、任意の詳細を更新することができます。

変数を設定したら、.gitlab-ci.ymlファイルから呼び出します。 

test_variable:
  stage: test
  script:
    - echo $CI_JOB_STAGE # calls a predefined variable
    - echo $TEST # calls a custom variable of type `env_var`
    - echo $GREETING # calls a custom variable of type `file` that contains the path to the temp file
    - cat $GREETING # the temp file itself contains the variable value

次のように出力されます。

Output custom variable

Variable 型のカスタム環境変数

GitLab 11.11で導入されました。

Variable型の変数では、Runnerは名前にキーを、値に値を使用する環境変数を作成します。

この型の定義済み変数がいくつかあり、さらに検証することができます。 これらは、UIで変数を追加または更新したときに表示されます。

File 型のカスタム環境変数

GitLab 11.11で導入されました。

File型の変数では、Runnerは名前にキーを使用する環境変数を作成します。 値では、Runnerは変数値を一時ファイルに書き込み、このパスを使用します。

AWS CLIや kubectlなどのツールを使用して、File型変数を使用して、設定をカスタマイズします。

以前は、CI変数の値を読み込んでファイルに保存し、新たに作成したファイルをスクリプトで使用するというパターンが一般的でした。 

# Read certificate stored in $KUBE_CA_PEM variable and save it in a new file
echo "$KUBE_CA_PEM" > "$(pwd)/kube.ca.pem"
# Pass the newly created file to kubectl
kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$(pwd)/kube.ca.pem"

この代わりに、File型変数を使うことができます。 例えば、次のような変数があった場合。

  • Variable型の変数KUBE_URLで、値はhttps://example.com。
  • File型の変数KUBE_CA_PEMで、値として証明書を指定。

.gitlab-ci.ymlから以下のように呼び出すことができます。 

kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$KUBE_CA_PEM"

カスタム変数をマスクする

GitLab 11.10 で導入されました。

変数の値がジョブログに表示されないように、変数をマスクすることができます。

変数をマスクするには

  1. 設定 > CI/CDを選択します。
  2. 変数セクションを展開します。
  3. 保護したい変数の横で、編集をクリックします。
  4. 変数をマスクチェックボックスを選択します。
  5. 変数を更新をクリックします。

マスク変数の要件

次の変数の値が必要です。

  • 一行であること。
  • 8文字以上であること。
  • 定義済みまたはカスタム環境変数でないこと。
  • Base64アルファベット(RFC4648)の文字のみで構成される。GitLab 12.2以降では、@と:も有効な値である。

これらの条件を満たさない変数をマスクすることはできません。

カスタム変数の保護

GitLab 9.3から導入されました。

変数を保護すると、保護ブランチや保護タグで実行されるパイプラインにのみ安全に渡されます。 他のパイプラインでは保護変数を取得することはできません。

変数を保護するには

  1. 設定 > CI/CDを選択します。
  2. 変数セクションを展開します。
  3. 保護したい変数の横で、編集をクリックします。
  4. 変数の保護チェックボックスを選択します。
  5. 変数を更新をクリックします。

この変数は、それ以降のすべてのパイプラインで利用可能です。

GitLabで検証されたカスタム変数

GitLabはこれらの変数の値が正しい形式であることを確認するために検証を行います。

変数 許容される値 次で導入されました
AWS_ACCESS_KEY_ID 20文字：英字、数字 12.10
AWS_DEFAULT_REGION 任意 12.10
AWS_SECRET_ACCESS_KEY 40文字：英字、数字、特殊文字 12.10
Note:クレデンシャルを保存する場合、セキュリティ上の影響があります。 例えばAWSのキーを使用する場合、そのベストプラクティスに従ってください。

ジョブスクリプトにおける環境変数の構文

すべての変数は、ビルド環境の環境変数として設定され、そのような変数にアクセスするために使用される通常の方法でアクセスできます。 ほとんどの場合、ジョブスクリプトの実行には、bashまたはshが使用されます．

環境変数にアクセスするには、Runnerのシェルに対応した構文を使用します。

Shell 使用方法
bash/sh $variable
PowerShell $env:variable (primary) または $variable
Windows Batch %variable%

Bash

bashで環境変数にアクセスするには、変数名の前に($)を付けます。 

job_name:
  script:
    - echo $CI_JOB_ID

PowerShell

Windows PowerShell環境で環境変数にアクセスするには、変数名の前に($env:)を付けます。 システムで設定された環境変数は、($env:)でアクセスする必要があります。 

job_name:
  script:
    - echo $env:CI_JOB_ID
    - echo $CI_JOB_ID
    - echo $env:PATH

場合によっては、環境変数を正しく展開するために、引用符で囲む必要があることがあります。 

job_name:
  script:
    - D:\\qislsf\\apache-ant-1.10.5\\bin\\ant.bat "-DsosposDailyUsr=$env:SOSPOS_DAILY_USR" portal_test

Windows Batch

Windows Batchで環境変数にアクセスするには、変数を(%)で囲みます。 

job_name:
  script:
    - echo %CI_JOB_ID%

すべての環境変数をリストアップ

また、BashのexportコマンドやPowerShellのdir env:コマンドですべての環境変数を一覧することができます。 この場合、設定したすべての変数の値もジョブログで公開されることに注意してください。 

job_name:
  script:
    - export
    # - 'dir env:' # use this for PowerShell

値の例 

export CI_JOB_ID="50"
export CI_COMMIT_SHA="1ecfd275763eff1d6b4844ea3168962458c9f27a"
export CI_COMMIT_SHORT_SHA="1ecfd275"
export CI_COMMIT_REF_NAME="master"
export CI_REPOSITORY_URL="https://gitlab-ci-token:abcde-1234ABCD5678ef@example.com/gitlab-org/gitlab-foss.git"
export CI_COMMIT_TAG="1.0.0"
export CI_JOB_NAME="spec:other"
export CI_JOB_STAGE="test"
export CI_JOB_MANUAL="true"
export CI_JOB_TRIGGERED="true"
export CI_JOB_TOKEN="abcde-1234ABCD5678ef"
export CI_PIPELINE_ID="1000"
export CI_PIPELINE_IID="10"
export CI_PAGES_DOMAIN="gitlab.io"
export CI_PAGES_URL="https://gitlab-org.gitlab.io/gitlab-foss"
export CI_PROJECT_ID="34"
export CI_PROJECT_DIR="/builds/gitlab-org/gitlab-foss"
export CI_PROJECT_NAME="gitlab-foss"
export CI_PROJECT_TITLE="GitLab FOSS"
export CI_PROJECT_NAMESPACE="gitlab-org"
export CI_PROJECT_ROOT_NAMESPACE="gitlab-org"
export CI_PROJECT_PATH="gitlab-org/gitlab-foss"
export CI_PROJECT_URL="https://example.com/gitlab-org/gitlab-foss"
export CI_REGISTRY="registry.example.com"
export CI_REGISTRY_IMAGE="registry.example.com/gitlab-org/gitlab-foss"
export CI_REGISTRY_USER="gitlab-ci-token"
export CI_REGISTRY_PASSWORD="longalfanumstring"
export CI_RUNNER_ID="10"
export CI_RUNNER_DESCRIPTION="my runner"
export CI_RUNNER_TAGS="docker, linux"
export CI_SERVER="yes"
export CI_SERVER_URL="https://example.com"
export CI_SERVER_HOST="example.com"
export CI_SERVER_PORT="443"
export CI_SERVER_PROTOCOL="https"
export CI_SERVER_NAME="GitLab"
export CI_SERVER_REVISION="70606bf"
export CI_SERVER_VERSION="8.9.0"
export CI_SERVER_VERSION_MAJOR="8"
export CI_SERVER_VERSION_MINOR="9"
export CI_SERVER_VERSION_PATCH="0"
export GITLAB_USER_EMAIL="user@example.com"
export GITLAB_USER_ID="42"

.gitlab-ci.ymlで定義された変数

Note:この機能を利用するには、GitLab Runner 0.5.0以降とGitLab 7.14以降が必要です。

ビルド環境で設定される変数を.gitlab-ci.ymlに追加できます。これらの変数はリポジトリに保存され、RAILS_ENVやDATABASE_URLなど、機密性のないプロジェクト設定を保存するためのものです。

例えば、以下の変数をグローバルに設定した場合（ジョブ内ではない）、実行されるすべてのコマンドとスクリプトで使用されます。 

variables:
  DATABASE_URL: "postgres://postgres@postgres/my_database"

YAML定義の変数も、作成されたすべてのサービスコンテナに設定されるので、微調整が可能です。

変数はグローバルレベルだけでなく、ジョブレベルでも定義できます。 ジョブでグローバルに定義された変数をオフにするには、空のハッシュを定義してください。 

job_name:
  variables: {}

変数定義の中で他の変数を使用することができます（$$でエスケープすることもできます）。 

variables:
  LS_CMD: 'ls $FLAGS $$TMP_DIR'
  FLAGS: '-al'
script:
  - 'eval $LS_CMD'  # will execute 'ls -al $TMP_DIR'

グループレベルの環境変数

GitLab 9.4 で導入されました。

パイプライン環境に設定される、プロジェクト単位またはグループ単位の変数を定義できます。 グループレベルの変数は、リポジトリの外に保存され（.gitlab-ci.ymlではありません）、GitLab Runnerに安全に渡され、パイプライン実行中に利用できます。 外部キーストアを使用しないPremiumユーザーや、GitLabとHashiCorp Vaultインテグレーションを使用している場合は、パスワード、SSHキー、認証情報などのクレデンシャルを保存するのにグループ環境変数を使っていただくようおすすめしています。

次のようにグループレベルの変数を追加することができるます。

  1. グループの設定 > CI/CDのページに移動する。
  2. 変数セクションの変数タイプ、キー、値を入力する。サブグループの変数はすべて再帰的に継承される。

一度設定すると、それ以降のパイプラインで利用できるようになります。 グループレベルのユーザー定義変数は、以下の方法でプロジェクトで確認することができます。

  1. プロジェクトの設定 > CI/CDのページに移動する。
  2. 変数セクションを展開する。

CI/CD settings - inherited variables

インスタンスレベルのCI/CD環境変数

GitLab 13.0から導入されました。

インスタンス変数は、すべてのプロジェクトで同じ認証情報を繰り返し手動で入力する必要がなくなるので便利です。 インスタンスレベルの変数は、インスタンス上のすべてのプロジェクトとグループで利用可能です。

Note:インスタンスレベル変数の最大数は25個を予定しています。

インスタンスレベルの変数は、UIやAPIから定義することができます。

インスタンスレベルの変数を追加する場合には

  1. 管理画面の設定 > CI/CDを開き、変数セクションを展開します。

  2. 変数の追加]ボタンをクリックし、詳細を入力します。

    • Key：1行で、英字、数字、_（アンダースコア）のみを使用し、スペースを入れないこと。
    • Value：700文字まで許容される。
    • Type：FileまたはVariable。
    • 変数の保護（オプション）：選択すると、保護ブランチまたはタグで実行されるパイプラインでのみ変数が利用可能になります。
    • 変数のマスク（オプション）：選択した場合、変数の値はジョブログに表示されません。 値がマスクの要件を満たしていない場合、変数は保存されません。

変数の作成後、 編集ボタンをクリックすると、任意の詳細を更新することができます。

インスタンスレベルのCI/CD変数のUIインターフェイスの有効化・無効化

インスタンスレベルのCI/CD変数のUIインターフェースは開発中ですが、実運用に使用する準備ができています。 これはデフォルトで有効になっている機能フラグの後ろに配備されています。GitLab RailsコンソールにアクセスできるGitLab管理者は、あなたのインスタンスの機能フラグを無効にすることを選択できます。

無効化するには: 

Feature.disable(:instance_variables_ui)

有効にするには: 

Feature.enable(:instance_variables_ui)

環境変数の継承

依存するジョブから環境変数を継承することができます。

この機能は artifacts:reports:dotenvレポート機能で利用します。

dependenciesキーワードを使った例。 

build:
  stage: build
  script:
    - echo "BUILD_VERSION=hello" >> build.env
  artifacts:
    reports:
      dotenv: build.env

deploy:
  stage: deploy
  script:
    - echo $BUILD_VERSION # => hello
  dependencies:
    - build

needsキーワードを使った例。 

build:
  stage: build
  script:
    - echo "BUILD_VERSION=hello" >> build.env
  artifacts:
    reports:
      dotenv: build.env

deploy:
  stage: deploy
  script:
    - echo $BUILD_VERSION # => hello
  needs:
    - job: build
      artifacts: true

環境変数の優先順位

異なるタイプの変数は、定義される場所によって、他の変数より優先されることがあります。

変数の優先順位の高いものから低いものです。

  1. トリガー変数、スケジュールされたパイプライン変数、手動パイプライン実行変数。
  2. プロジェクトレベルの変数または保護変数。
  3. グループレベルの変数または保護変数。
  4. 継承された環境変数。
  5. YAMLで定義されたジョブレベルの変数。
  6. YAMLで定義されたグローバル変数。
  7. デプロイメント変数。
  8. 事前定義された環境変数。

例えば、次のように定義した場合。

  • プロジェクト変数としてAPI_TOKEN=secureを指定します。
  • .gitlab-ci.ymlでAPI_TOKEN=yamlを指定します。

API_TOKENは、.gitlab-ci.ymlで定義されたものよりもプロジェクトの変数が優先されるため、secureの値をとります。

サポートされていない変数

変数名はスクリプトの実行に使用するシェルによって制限されます（使用可能なシェルを参照。 各シェルには独自の予約変数名のセットがあります。 また、環境変数のスコープを覚えておき、使用するスコープで変数が定義されていることを確認する必要があります。

変数が使用できる場所

異なるタイプの変数をどこでどのように使用できるかを説明したセクションはこちらです。

高度な利用

環境変数の環境スコープを限定する

ある変数がどの環境で利用できるかを定義することで、その変数の環境範囲を限定することができます。

スコープ環境について詳しくは、スペックによるスコープ環境をご覧ください。

デプロイメント環境変数

GitLab 8.15 で導入されました。

デプロイメント設定を行うインテグレーションは、ビルド環境で設定される独自の変数を定義することができます。 これらの変数はデプロイメントジョブでのみ定義されます。 どの変数を定義するかは、使用しているインテグレーションのドキュメントを参照してください。

デプロイメント変数を定義する統合の例として、Kubernetesインテグレーションがあります。

Auto DevOps環境変数

GitLab 11.7 で導入されました。

Auto DevOpsでは、変数のキーの前にK8S_SECRET_を付けることで、実行中のアプリケーションにCI変数を渡すように設定することができます。

これらの接頭辞付きの変数は、実行中のアプリケーションコンテナ上で環境変数として利用できるようになります。

Caution:現在のAuto DevOpsスクリプト環境では制限されているため、複数行の値を持つ変数は現在サポートされていません。

パイプラインを手動で実行することで変数をオーバーライドする

GitLab 10.8で導入されました。

パイプラインを手動で実行することにより、現在の変数の値を上書きすることができます。

例えば、$TESTというカスタム変数を追加して、それを手動パイプラインで上書きしたいとします。

プロジェクトのCI/CD > Pipelinesに移動し、Run pipelineをクリックします。 パイプラインを実行したいブランチを選択し、UIで変数とその値を追加してください。

Override variable value

Runnerは、以前に設定した値を上書きし、この特定のパイプラインのカスタム値を使用します。

Manually overridden variable output

環境変数の評価式

GitLabに変更をプッシュした後、パイプライン内で作成されるジョブを制限するために、変数式を使用します。

.gitlab-ci.ymlでは、次の変数式は両方で動作します。

特に変数やトリガーされたパイプライン変数との組み合わせで有効です。 

deploy:
  script: cap staging deploy
  environment: staging
  only:
    variables:
      - $RELEASE == "staging"
      - $STAGING

提供された各式は、パイプラインが作成される前に評価されます。

only使用時に変数中のいずれかの条件がtrueと評価された場合、新しいジョブが作成されます。except使用時にいずれかの条件がtrueと評価された場合、ジョブは作成されません。

これは、only/exceptポリシーの通常のルールに従います。

環境変数式の構文

以下は、サポートされている構文のリファレンスです。

  1. 文字列を用いた等式マッチング

    例：

    • $VARIABLE == "some value"
    • $VARIABLE != "some value" (GitLab 11.11で導入)

    等号演算子==や!=を使って、変数の内容と文字列を比較することができます。 文字列の値を定義するのに、二重引用符と一重引用符の両方をサポートしているので、$VARIABLE == "some value"や$VARIABLE == 'some value'はどちらもサポートされています。

  2. 未定義の値をチェックする

    例：

    • $VARIABLE == null
    • $VARIABLE != null (GitLab 11.11で導入)

    変数が定義されているかどうかを調べたいとき、$VARIABLE == nullのようにnullキーワードと比較することができます。 この式は==が使われると変数が定義されていない場合は真、!=が使われると偽と評価されます。

  3. 変数が空かどうかのチェック

    例：

    • $VARIABLE == ""
    • $VARIABLE != "" (GitLab 11.11で導入)

    変数が定義されているが、空であるかどうかを確認したい場合は、$VAR == ''や空でない文字列$VARIABLE != ""のように、単純に空文字列と比較することができます。

  4. 2つの変数を比較する

    例：

    • $VARIABLE_1 == $VARIABLE_2
    • $VARIABLE_1 != $VARIABLE_2 (GitLab 11.11で導入)

    2つの変数を比較することができます。 これは、これらの変数の値を比較することになります。

  5. 変数の有無の確認

    例: $STAGING

    もし、ある変数が存在し、それが定義され、空でない場合にのみジョブを作成したい場合、$STAGINGのように変数名を式として使用することができます。 もし$STAGING変数が定義されていて、空でなければ、式は真と評価されます。$STAGING値は0以上の長さの文字列である必要があります。 空白文字だけを含む変数は空変数とは言えません。

  6. パターンマッチ (GitLab 11.0 で導入)

    例：

    • =~: パターンにマッチした場合に真。 例:$VARIABLE =~ /^content.*/
    • !~: パターンにマッチしない場合に真。 例:$VARIABLE_1 !~ /^content.*/(GitLab 11.11 で導入されました)

    正規表現による変数パターンマッチは、RE2正規表現構文を使用します。 式は、次の場合に真として評価されます。

    • =~を使用した一致する場合に場合マッチします。
    • !~を使用した一致しない場合にマッチします。

    パターンマッチはデフォルトで大文字・小文字を区別しますが、/pattern/iのようなiフラグ修飾子を使うと、大文字・小文字を区別しないパターンにすることができます。

  7. Conjunction / Disjunction(GitLab 12.0 で導入)

    例：

    • $VARIABLE1 =~ /^content.*/ && $VARIABLE2 == "something"
    • $VARIABLE1 =~ /^content.*/ && $VARIABLE2 =~ /thing$/ && $VARIABLE3
    • $VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/ && $VARIABLE3

    複数の条件を&&や||で結合することができます。 他のサポートされている構文は、接続文や分離文で使用することができます。 演算子の優先順位はRuby 2.5 標準に従っているので、&&は||よりも先に評価されます。

正規表現を変数に格納する

正規表現を変数に格納し、パターンマッチに使用することが可能です。 

variables:
  STAGINGRELS: '/staging0|staging1/'

deploy_staging:
  script: do.sh deploy staging
  environment: staging
  rules:
    - if: '$RELEASE =~ $STAGINGRELS'

NOTE:Note:利用可能な正規表現構文には制限があります。 詳細は関連するイシューを参照してください。

必要に応じて、テストパイプラインを使用して、正規表現が変数内で動作するかどうかを判断できます。 以下の例では、変数内からだけでなく、^mast.*正規表現を直接テストしています。 

variables:
  MYSTRING: 'master'
  MYREGEX: '/^mast.*/'

testdirect:
  script: /bin/true
  rules:
    - if: '$MYSTRING =~ /^mast.*/'

testvariable:
  script: /bin/true
  rules:
    - if: '$MYSTRING =~ $MYREGEX'

デバッグロギング

GitLab Runner 1.7 で導入されました。

Warning:デバッグトレースを有効にすると、深刻なセキュリティ上の影響があります。 出力には、すべての変数の内容とその他のクレデンシャルが含まれます！出力はGitLabサーバーにアップロードされ、ジョブログで可視化されます！

GitLab Runner はデフォルトで、ジョブを処理する際に行っていることの詳細をほとんど隠します。 この動作により、ジョブのログを短く保ち、スクリプトが画面に書き込まない限り、ログにクレデンシャルが漏れるのを防ぐことができます。

ジョブが期待したように動作しないと、その調査は大変になります。そのような場合、GitLab Runner v1.7+ では、.gitlab-ci.gitlab-ci.ymlでシェルの実行ログを有効にして、実行したコマンドや設定した変数などの詳細なジョブログを表示することができます。

この機能を有効にする前に、ジョブがチームメンバーだけに見えるようにする必要があります。 また、生成されたジョブログをすべて消去してから、他のメンバーにも再び見えるようにする必要があります。

デバッグログ（トレース）を有効にするには、CI_DEBUG_TRACE変数をtrueに設定します。 

job_name:
  variables:
    CI_DEBUG_TRACE: "true"

CI_DEBUG_TRACEをtrueに設定した場合の出力例です。 

...

export CI_SERVER_TLS_CA_FILE="/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE"
if [[ -d "/builds/gitlab-examples/ci-debug-trace/.git" ]]; then
  echo $'\''\x1b[32;1mFetching changes...\x1b[0;m'\''
  $'\''cd'\'' "/builds/gitlab-examples/ci-debug-trace"
  $'\''git'\'' "config" "fetch.recurseSubmodules" "false"
  $'\''rm'\'' "-f" ".git/index.lock"
  $'\''git'\'' "clean" "-ffdx"
  $'\''git'\'' "reset" "--hard"
  $'\''git'\'' "remote" "set-url" "origin" "https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@example.com/gitlab-examples/ci-debug-trace.git"
  $'\''git'\'' "fetch" "origin" "--prune" "+refs/heads/*:refs/remotes/origin/*" "+refs/tags/*:refs/tags/lds"
++ CI_BUILDS_DIR=/builds
++ export CI_PROJECT_DIR=/builds/gitlab-examples/ci-debug-trace
++ CI_PROJECT_DIR=/builds/gitlab-examples/ci-debug-trace
++ export CI_CONCURRENT_ID=87
++ CI_CONCURRENT_ID=87
++ export CI_CONCURRENT_PROJECT_ID=0
++ CI_CONCURRENT_PROJECT_ID=0
++ export CI_SERVER=yes
++ CI_SERVER=yes
++ mkdir -p /builds/gitlab-examples/ci-debug-trace.tmp
++ echo -n '-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----'
++ export CI_SERVER_TLS_CA_FILE=/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE
++ CI_SERVER_TLS_CA_FILE=/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE
++ export CI_PIPELINE_ID=52666
++ CI_PIPELINE_ID=52666
++ export CI_PIPELINE_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/pipelines/52666
++ CI_PIPELINE_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/pipelines/52666
++ export CI_JOB_ID=7046507
++ CI_JOB_ID=7046507
++ export CI_JOB_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/-/jobs/379424655
++ CI_JOB_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/-/jobs/379424655
++ export CI_JOB_TOKEN=[MASKED]
++ CI_JOB_TOKEN=[MASKED]
++ export CI_BUILD_ID=379424655
++ CI_BUILD_ID=379424655
++ export CI_BUILD_TOKEN=[MASKED]
++ CI_BUILD_TOKEN=[MASKED]
++ export CI_REGISTRY_USER=gitlab-ci-token
++ CI_REGISTRY_USER=gitlab-ci-token
++ export CI_REGISTRY_PASSWORD=[MASKED]
++ CI_REGISTRY_PASSWORD=[MASKED]
++ export CI_REPOSITORY_URL=https://gitlab-ci-token:[MASKED]@gitlab.com/gitlab-examples/ci-debug-trace.git
++ CI_REPOSITORY_URL=https://gitlab-ci-token:[MASKED]@gitlab.com/gitlab-examples/ci-debug-trace.git
++ export CI_JOB_NAME=debug_trace
++ CI_JOB_NAME=debug_trace
++ export CI_JOB_STAGE=test
++ CI_JOB_STAGE=test
++ export CI_NODE_TOTAL=1
++ CI_NODE_TOTAL=1
++ export CI_BUILD_NAME=debug_trace
++ CI_BUILD_NAME=debug_trace
++ export CI_BUILD_STAGE=test
++ CI_BUILD_STAGE=test
++ export CI=true
++ CI=true
++ export GITLAB_CI=true
++ GITLAB_CI=true
++ export CI_SERVER_URL=https://gitlab.com:3000
++ CI_SERVER_URL=https://gitlab.com:3000
++ export CI_SERVER_HOST=gitlab.com
++ CI_SERVER_HOST=gitlab.com
++ export CI_SERVER_PORT=3000
++ CI_SERVER_PORT=3000
++ export CI_SERVER_PROTOCOL=https
++ CI_SERVER_PROTOCOL=https
++ export CI_SERVER_NAME=GitLab
++ CI_SERVER_NAME=GitLab
++ export CI_SERVER_VERSION=12.6.0-pre
++ CI_SERVER_VERSION=12.6.0-pre
++ export CI_SERVER_VERSION_MAJOR=12
++ CI_SERVER_VERSION_MAJOR=12
++ export CI_SERVER_VERSION_MINOR=6
++ CI_SERVER_VERSION_MINOR=6
++ export CI_SERVER_VERSION_PATCH=0
++ CI_SERVER_VERSION_PATCH=0
++ export CI_SERVER_REVISION=f4cc00ae823
++ CI_SERVER_REVISION=f4cc00ae823
++ export GITLAB_FEATURES=audit_events,burndown_charts,code_owners,contribution_analytics,description_diffs,elastic_search,group_bulk_edit,group_burndown_charts,group_webhooks,issuable_default_templates,issue_weights,jenkins_integration,ldap_group_sync,member_lock,merge_request_approvers,multiple_issue_assignees,multiple_ldap_servers,multiple_merge_request_assignees,protected_refs_for_users,push_rules,related_issues,repository_mirrors,repository_size_limit,scoped_issue_board,usage_quotas,visual_review_app,wip_limits,adjourned_deletion_for_projects_and_groups,admin_audit_log,auditor_user,batch_comments,blocking_merge_requests,board_assignee_lists,board_milestone_lists,ci_cd_projects,cluster_deployments,code_analytics,code_owner_approval_required,commit_committer_check,cross_project_pipelines,custom_file_templates,custom_file_templates_for_namespace,custom_project_templates,custom_prometheus_metrics,cycle_analytics_for_groups,db_load_balancing,default_project_deletion_protection,dependency_proxy,deploy_board,design_management,email_additional_text,extended_audit_events,external_authorization_service_api_management,feature_flags,file_locks,geo,github_project_service_integration,group_allowed_email_domains,group_project_templates,group_saml,issues_analytics,jira_dev_panel_integration,ldap_group_sync_filter,merge_pipelines,merge_request_performance_metrics,merge_trains,metrics_reports,multiple_approval_rules,multiple_group_issue_boards,object_storage,operations_dashboard,packages,productivity_analytics,project_aliases,protected_environments,reject_unsigned_commits,required_ci_templates,scoped_labels,service_desk,smartcard_auth,group_timelogs,type_of_work_analytics,unprotection_restrictions,ci_project_subscriptions,container_scanning,dast,dependency_scanning,epics,group_ip_restriction,incident_management,insights,license_management,personal_access_token_expiration_policy,pod_logs,prometheus_alerts,pseudonymizer,report_approver_rules,sast,security_dashboard,tracing,web_ide_terminal
++ GITLAB_FEATURES=audit_events,burndown_charts,code_owners,contribution_analytics,description_diffs,elastic_search,group_bulk_edit,group_burndown_charts,group_webhooks,issuable_default_templates,issue_weights,jenkins_integration,ldap_group_sync,member_lock,merge_request_approvers,multiple_issue_assignees,multiple_ldap_servers,multiple_merge_request_assignees,protected_refs_for_users,push_rules,related_issues,repository_mirrors,repository_size_limit,scoped_issue_board,usage_quotas,visual_review_app,wip_limits,adjourned_deletion_for_projects_and_groups,admin_audit_log,auditor_user,batch_comments,blocking_merge_requests,board_assignee_lists,board_milestone_lists,ci_cd_projects,cluster_deployments,code_analytics,code_owner_approval_required,commit_committer_check,cross_project_pipelines,custom_file_templates,custom_file_templates_for_namespace,custom_project_templates,custom_prometheus_metrics,cycle_analytics_for_groups,db_load_balancing,default_project_deletion_protection,dependency_proxy,deploy_board,design_management,email_additional_text,extended_audit_events,external_authorization_service_api_management,feature_flags,file_locks,geo,github_project_service_integration,group_allowed_email_domains,group_project_templates,group_saml,issues_analytics,jira_dev_panel_integration,ldap_group_sync_filter,merge_pipelines,merge_request_performance_metrics,merge_trains,metrics_reports,multiple_approval_rules,multiple_group_issue_boards,object_storage,operations_dashboard,packages,productivity_analytics,project_aliases,protected_environments,reject_unsigned_commits,required_ci_templates,scoped_labels,service_desk,smartcard_auth,group_timelogs,type_of_work_analytics,unprotection_restrictions,ci_project_subscriptions,cluster_health,container_scanning,dast,dependency_scanning,epics,group_ip_restriction,incident_management,insights,license_management,personal_access_token_expiration_policy,pod_logs,prometheus_alerts,pseudonymizer,report_approver_rules,sast,security_dashboard,tracing,web_ide_terminal
++ export CI_PROJECT_ID=17893
++ CI_PROJECT_ID=17893
++ export CI_PROJECT_NAME=ci-debug-trace
++ CI_PROJECT_NAME=ci-debug-trace
++ export CI_PROJECT_TITLE='GitLab FOSS'
++ CI_PROJECT_TITLE='GitLab FOSS'
++ export CI_PROJECT_PATH=gitlab-examples/ci-debug-trace
++ CI_PROJECT_PATH=gitlab-examples/ci-debug-trace
++ export CI_PROJECT_PATH_SLUG=gitlab-examples-ci-debug-trace
++ CI_PROJECT_PATH_SLUG=gitlab-examples-ci-debug-trace
++ export CI_PROJECT_NAMESPACE=gitlab-examples
++ CI_PROJECT_NAMESPACE=gitlab-examples
++ export CI_PROJECT_ROOT_NAMESPACE=gitlab-examples
++ CI_PROJECT_ROOT_NAMESPACE=gitlab-examples
++ export CI_PROJECT_URL=https://gitlab.com/gitlab-examples/ci-debug-trace
++ CI_PROJECT_URL=https://gitlab.com/gitlab-examples/ci-debug-trace
++ export CI_PROJECT_VISIBILITY=public
++ CI_PROJECT_VISIBILITY=public
++ export CI_PROJECT_REPOSITORY_LANGUAGES=
++ CI_PROJECT_REPOSITORY_LANGUAGES=
++ export CI_DEFAULT_BRANCH=master
++ CI_DEFAULT_BRANCH=master
++ export CI_REGISTRY=registry.gitlab.com
++ CI_REGISTRY=registry.gitlab.com
++ export CI_API_V4_URL=https://gitlab.com/api/v4
++ CI_API_V4_URL=https://gitlab.com/api/v4
++ export CI_PIPELINE_IID=123
++ CI_PIPELINE_IID=123
++ export CI_PIPELINE_SOURCE=web
++ CI_PIPELINE_SOURCE=web
++ export CI_CONFIG_PATH=.gitlab-ci.yml
++ CI_CONFIG_PATH=.gitlab-ci.yml
++ export CI_COMMIT_SHA=dd648b2e48ce6518303b0bb580b2ee32fadaf045
++ CI_COMMIT_SHA=dd648b2e48ce6518303b0bb580b2ee32fadaf045
++ export CI_COMMIT_SHORT_SHA=dd648b2e
++ CI_COMMIT_SHORT_SHA=dd648b2e
++ export CI_COMMIT_BEFORE_SHA=0000000000000000000000000000000000000000
++ CI_COMMIT_BEFORE_SHA=0000000000000000000000000000000000000000
++ export CI_COMMIT_REF_NAME=master
++ CI_COMMIT_REF_NAME=master
++ export CI_COMMIT_REF_SLUG=master
++ CI_COMMIT_REF_SLUG=master
++ export CI_COMMIT_MESSAGE=s/CI/Runner
++ CI_COMMIT_MESSAGE=s/CI/Runner
++ export CI_COMMIT_TITLE=s/CI/Runner
++ CI_COMMIT_TITLE=s/CI/Runner
++ export CI_COMMIT_DESCRIPTION=
++ CI_COMMIT_DESCRIPTION=
++ export CI_COMMIT_REF_PROTECTED=true
++ CI_COMMIT_REF_PROTECTED=true
++ export CI_BUILD_REF=dd648b2e48ce6518303b0bb580b2ee32fadaf045
++ CI_BUILD_REF=dd648b2e48ce6518303b0bb580b2ee32fadaf045
++ export CI_BUILD_BEFORE_SHA=0000000000000000000000000000000000000000
++ CI_BUILD_BEFORE_SHA=0000000000000000000000000000000000000000
++ export CI_BUILD_REF_NAME=master
++ CI_BUILD_REF_NAME=master
++ export CI_BUILD_REF_SLUG=master
++ CI_BUILD_REF_SLUG=master
++ export CI_RUNNER_ID=1337
++ CI_RUNNER_ID=1337
++ export CI_RUNNER_DESCRIPTION=shared-runners-manager-4.gitlab.com
++ CI_RUNNER_DESCRIPTION=shared-runners-manager-4.gitlab.com
++ export 'CI_RUNNER_TAGS=gce, east-c, shared, docker, linux, ruby, mysql, postgres, mongo, git-annex'
++ CI_RUNNER_TAGS='gce, east-c, shared, docker, linux, ruby, mysql, postgres, mongo, git-annex'
++ export CI_DEBUG_TRACE=true
++ CI_DEBUG_TRACE=true
++ export GITLAB_USER_ID=42
++ GITLAB_USER_ID=42
++ export GITLAB_USER_EMAIL=user@example.com
++ GITLAB_USER_EMAIL=user@example.com
++ export GITLAB_USER_LOGIN=root
++ GITLAB_USER_LOGIN=root
++ export 'GITLAB_USER_NAME=User'
++ GITLAB_USER_NAME='User'
++ export CI_DISPOSABLE_ENVIRONMENT=true
++ CI_DISPOSABLE_ENVIRONMENT=true
++ export CI_RUNNER_VERSION=12.5.0
++ CI_RUNNER_VERSION=12.5.0
++ export CI_RUNNER_REVISION=577f813d
++ CI_RUNNER_REVISION=577f813d
++ export CI_RUNNER_EXECUTABLE_ARCH=linux/amd64
++ CI_RUNNER_EXECUTABLE_ARCH=linux/amd64
++ export VERY_SECURE_VARIABLE=imaverysecurevariable
++ VERY_SECURE_VARIABLE=imaverysecurevariable

...

動作例のビデオ・ウォークスルー

Complex Configuration Data Management Monster Using GitLabのビデオは、Complex Config Data Monorepoの作業例プロジェクトのウォークスルーです。 複数レベルのグループCI/CD変数と環境スコープのプロジェクト変数を組み合わせて、アプリケーションのビルドやデプロイメントを複雑に設定する方法について説明します。

このサンプルは、自分のグループやインスタンスにコピーしてテストすることができます。 他のGitLab CIパターンがどのようにデモされているかの詳細は、プロジェクトページで確認できます。