環境変数は、パイプラインをカスタマイズするための一般的な方法で、任意のステージで使用できます。このトピックでは、環境変数の種類 (組み込み、カスタム、および共通変数グループ) とその使用方法について説明します。
環境変数のソース
組み込み変数
Alibaba Cloud DevOps パイプラインは、基本情報とコードソースに関連する組み込み変数を提供します。これらの変数を使用して、ワークフローをカスタマイズできます。
|
モジュール |
パラメーター |
説明 |
|
基本情報 |
PIPELINE_ID |
パイプラインの ID です。 |
|
BUILD_NUMBER |
パイプラインの実行番号です。1 から始まり、実行ごとにインクリメントされます。 |
|
|
PIPELINE_NAME |
パイプラインの名前です。例: |
|
|
BUILD_REMARK |
パイプライン実行の注釈です。 |
|
|
BUILD_EXECUTOR |
パイプラインをトリガーしたユーザーです。例: |
|
|
BUILD_MESSAGE |
パイプラインのトリガー情報です。例: |
|
|
PROJECT_DIR |
コマンドを実行するための作業ディレクトリです。例: |
|
|
DATETIME |
現在の時刻です。例: |
|
|
TIMESTAMP |
現在のタイムスタンプです。例: |
|
|
コードソース (単一) |
CI_SOURCE_NAME |
コードソースの名前です。 |
|
CI_COMMIT_REF_NAME |
パイプラインの実行中に選択されたコードソースのブランチ名またはタグ名です。例: |
|
|
CI_COMMIT_TITLE |
最後のコミットのメッセージです。 |
|
|
CI_COMMIT_SHA |
最後のコミットの完全なコミット ID です。例: |
|
|
CI_COMMIT_ID |
最後のコミットの 8 文字の短いコミット ID です (Git の場合)。 最後のコミットのリビジョン番号です (SVN の場合)。 |
|
|
コードソース (複数) |
CI_SOURCE_NAME_n |
n 番目のコードソースの名前です。 |
|
CI_COMMIT_REF_NAME_n |
パイプラインの実行中に選択された n 番目のコードソースのブランチ名またはタグ名です。例: |
|
|
CI_COMMIT_TITLE_n |
n 番目のコードソースの最後のコミットのメッセージです。 |
|
|
CI_COMMIT_SHA_n |
n 番目のコードソースの最後のコミットの完全なコミット ID です。例: |
|
|
CI_COMMIT_ID_n |
n 番目のコードソースの最後のコミットの 8 文字の短いコミット ID です (Git の場合)。 |
|
|
アーティファクトソース |
CI_SOURCE_NAME |
アーティファクトソースの名前です。 |
|
CI_SOURCE_URL |
アーティファクトソースの URL です。例: |
|
|
CI_VERSION_NAME |
パイプラインの実行中に選択されたアーティファクトソースのバージョン名です。例: |
複数のコードソースまたはアーティファクトソースが存在する場合、特定のソースの情報にアクセスするには、変数名に数字のサフィックスを追加します。
たとえば、パイプラインに Git コードソース (ソース 1) 、アーティファクトソース (ソース 2) 、および SVN コードソース (ソース 3) を含めることができます。パイプラインの実行後、実行の詳細ですべての変数の実際の値を確認できます。数字のサフィックスは、CI_COMMIT_REF_NAME_1 や CI_COMMIT_REF_NAME_2 のように、複数のソースの変数を区別します。
CI_COMMIT_REF_NAME 変数の値は、パイプラインをトリガーするときに選択する特定のブランチまたはタグによって異なります。パイプラインを手動でトリガーし、master ブランチを選択した場合、CI_COMMIT_REF_NAME の値は master になります。V1.0 タグを選択した場合、その値は V1.0 になります。この実行時の選択により、異なるブランチやタグでパイプラインを実行でき、変数の値もそれに応じて変化します。
パイプラインの実行をトリガーする際、実行ダイアログボックスで特定のブランチまたはタグを選択できます。選択した値が CI_COMMIT_REF_NAME 変数の実行時の値になります。
組み込み変数を使用する際は、次の制限事項と特殊なシナリオに注意してください:
-
複数ソース変数の曖昧さ — パイプラインに複数のコードソースがある場合、
CI_COMMIT_REF_NAMEのようなインデックスのない変数を直接使用しないでください。システムはデフォルトで最初のソースを参照しますが、結果は予測できません。特定のコードソースを参照するには、常にCI_COMMIT_REF_NAME_1やCI_COMMIT_REF_NAME_2のような数字のサフィックスが付いたインデックス付き変数を使用してください。 -
Git 変数の前提条件 —
CI_COMMIT_TITLE、CI_COMMIT_SHA、CI_COMMIT_IDなどの Git 関連の組み込み変数は、パイプラインでコードのチェックアウトステップが実行された後にのみ設定されます。コードがチェックアウトされていない場合、これらの変数は空になります。 -
変数処理の制限 — Alibaba Cloud DevOps Flow は、
CI_COMMIT_IDなどの組み込み変数に対する部分文字列の抽出や正規表現のマッチングなどの直接的な文字列操作をサポートしていません。組み込み変数の値を処理するには、シェルスクリプトでカスタム変数に割り当ててから、そのカスタム変数に対して操作を実行します:# 処理のために組み込み変数をカスタム変数に割り当てる MY_SHORT_SHA=$(echo $CI_COMMIT_SHA | cut -c1-8) echo "MY_SHORT_SHA=$MY_SHORT_SHA" >> "$FLOW_ENV" -
CI_WORKSPACE のスコープ —
CI_WORKSPACE変数は、現在のビルド環境内でのみ有効です。ホスト (ECS) へのデプロイシナリオでは、この変数が空になるか、予期しないパスを指す場合があります。ECS インスタンス上のファイルを見つけるためにCI_WORKSPACEに依存しないでください。代わりに、絶対パスを使用するか、ターゲットディレクトリのパスを指定したカスタム変数を設定してください。 -
欠落している組み込み変数 — 組み込み変数には、現在のリポジトリプロジェクト名や完全な Git URL は含まれません。この情報を取得するには、カスタム変数を手動で設定するか、Codeup ドメインとリポジトリパスを組み合わせて URL を構築してください。
カスタム変数
組み込み変数に加えて、Alibaba Cloud DevOps Flow はカスタム変数をサポートしています。各カスタム変数のスコープは、それが定義されているパイプラインに限定されます。カスタム変数を作成するには、パイプラインを選択し、[Edit] をクリックしてから、[Variables and Cache] タブに移動します。Alibaba Cloud DevOps Flow は、文字列型と列挙型の変数をサポートしています。
このタブには、文字列変数とランタイム選択変数の設定エリアがあります。
文字列変数
-
[Variables and Cache] タブの [String Variables] セクションで、[New Variable] をクリックします。
-
[Variable Name] と [Default Value] を入力します。[private mode] と [runtime settings] も設定できます。
-
[Variable Name]:名前にハイフン (-) を含めることはできません。
-
[private mode]:有効にすると、値が非表示になり、実行ログに表示されなくなります。ユーザー名やパスワードなどの機密情報に使用します。
-
[runtime settings]:変数の値が実行時に必要かどうかを制御します。有効にすると、パイプラインを実行するたびに値を指定する必要があります。
-
-
変数の追加や削除ができます。
-
[Add] をクリックし、パイプラインを保存します。これで、「環境変数の使用」で説明されているように変数を使用できます。
ランタイム選択変数
-
[Variables and Cache] タブの [Runtime-Selected Variables] セクションで、[New Variable] をクリックします。
-
[Variable Name] を入力し、[Options] を定義します。
-
[Add Option] をクリックして、変数の値の選択肢を複数追加します。
-
あるオプションの [Default Value] を有効にすると、それがデフォルトの選択肢になります。
-
-
[Add] をクリックしてパイプラインを保存します。これで、「環境変数の使用」で説明されているように変数を使用できます。
-
パイプラインを実行すると、この変数の値を選択するよう求められます。
カスタム変数のベストプラクティス
-
命名の競合を回避する — カスタム変数名は、
image、tag、versionなどのシステムの予約語や組み込みパラメーターと競合してはなりません。競合すると、イメージのビルドやデプロイのステップで予期しないエラーが発生する可能性があります。変数名は、文字で始まり、文字、数字、アンダースコアのみを含み、長さは 1 〜 64 文字である必要があります。 -
変数値の特殊文字を処理する — パスワードなどの変数値に
@などの特殊文字が含まれている場合、URL 内で値を直接連結するとフォーマットエラーが発生します。特殊文字を URL エンコードする (たとえば、@を%40に置き換える) か、[private mode] の変数を使用すると、システムが認証を自動的に処理します。 -
動的なコードソースの権限 — 動的に設定されたコードリポジトリにアクセスする際、パイプラインは実行者の ID で自動的に認証を行いません。プライベートリポジトリにアクセスするには、Git のユーザー名とアクセストークンをプライベート変数として設定するか、リポジトリをパイプラインソースとして追加してアクセス権限を継承します。
-
YAML ファイル内の変数参照をエスケープする —
kubectl applyのようなシナリオでは、YAML ファイル内の${}構文がパイプライン変数参照として誤って解釈されることがあります。これを防ぐには、[Variable Validation] オプションを有効にして自動変数解析を無効にするか、エスケープ構文$${}を使用して元の文字列を保持してください。たとえば、${2}の代わりに$${2}と記述します。
共通変数グループ
共通変数グループは、組織が一元管理する環境変数のコレクションです。パイプラインをグループに関連付けて、その変数を使用できます。
-
[Variables and Cache] タブの [Common Variable Group] セクションで、[Associate Variable Group] をクリックします。ドロップダウンリストから変数グループを選択し、[OK] をクリックしてパイプラインに関連付けます。
-
このセクションでは、関連付けられた変数グループの詳細の表示や関連付けの解除ができます。パイプラインを保存した後、「環境変数の使用」で説明されているように変数を使用できます。
環境変数の使用
変数を定義した後、${XXX} 構文を使用して、パイプライン内の任意の場所で変数を参照できます。システムは、以下の優先順位に従って変数を解決します。
-
ステップの出力変数 > パイプライン ランタイムの入力変数 > パイプライン変数 > 共通変数グループの変数
-
パイプラインに、同じ名前の変数を含む複数の共通変数グループを関連付けた場合、最後に関連付けられたグループの値が優先されます。
以降のセクションでは、コマンド実行、ホストデプロイメント、イメージビルド引数、設定ファイル、データの受け渡しといった、環境変数の一般的なユースケースの例を紹介します。
コマンドでの変数の使用
変数を使用して、設定ファイル内のパラメータを変更できます。たとえば、a.conf ファイル内の key パラメータの値を 123 から、abc という名前の環境変数の値に変更する場合などです。
シェルスクリプトのステップでは、 sed コマンドを使用してパラメーターの値を環境変数の値で置き換えます。
$ cat a.conf
key=123
$ sed -i "s/key=123/key=${abc}/g" a.conf
$ cat a.conf
key=abc_value

パイプラインの [変数とキャッシュ] で、変数 abc のデフォルト値を abc_value に設定します。
ホストデプロイメントにおける変数
${XXX} 構文を使用して、デプロイスクリプト内で環境変数を直接参照し、ホストデプロイのロジックをコントロールできます。パイプラインの実行後、ホストデプロイステップのログで、システムが変数の値を正しく渡したことを検証できます。
イメージビルド引数における変数
イメージビルド時にパイプラインの環境変数を引数として使用するには、次のように設定します。
-
イメージビルドのステップで、指定したコンテナ環境を使用します。ビルド引数にカスタム引数を追加し、
${XXX}フォーマットを使用してその引数に環境変数を割り当てます。システムは--build-argフラグを使用して、その引数をビルドコマンドに渡します。
イメージビルドステップの [Build Parameters] で、abc=${abc} のようなカスタム引数を追加します。この引数は、--build-arg として Docker ビルドコマンドに渡されます。

-
Dockerfile で、
ARG argNameで引数を参照します。
FROM <base-image>
ARG argName
RUN echo $argName
設定ファイルでの変数の使用
環境変数を使用して設定ファイル内のパラメーターを変更するには、次の手順に従ってください。たとえば、a.conf ファイル内の username パラメーターをパイプライン変数に置き換える場合:
-
a.conf ファイルで、行を
username = ${abc}に変更します。 -
パイプラインの環境変数で、
abc変数のデフォルト値をmy_name_is_hanmeimeiに設定します。 -
パイプラインにジョブを追加します。 [Utilities] セクションから、[Replace EnvVar in File] ステップを追加します。 [Source File Path] フィールドに設定ファイルのパスを入力します。 [Target File Path] はオプションです。 ターゲットパスを指定すると新しいファイルが作成され、指定しない場合は元のファイルが変更されます。
この例では、ソースファイルパス は a.conf に、ターゲットファイルパス は b.conf に設定されています。
-
結果を確認します。 このステップは、新しい
b.confファイルでa.conf内のusernameプレースホルダーを、変数の値my_name_is_hanmeimeiに置き換えます。 注:ステップは、同じジョブ内にある場合にのみワークスペースを共有します。
変数の受け渡し
パイプラインの設定ページで定義した環境変数は静的です。ただし、実行中のステップの出力から環境変数を生成し、後続のステップまたはジョブに渡す必要がある場合があります。これには、次の 2 つの方法があります:
-
ジョブ内で変数を渡す: ステップ 1 で生成したカスタム環境変数を、ステップ 2 で使用します。
-
ジョブ間で変数を渡す: ジョブ 1 で生成した環境変数を、ジョブ 2 で使用します。
重要:ビルド環境によって使用する構文が異なります。環境変数を設定するための構文は次のとおりです。デフォルト環境では echo 'USER_abc=123' > .env を使用します (変数名は USER_ で始まる必要があります)。指定されたコンテナ環境またはデフォルト VM 環境では echo "yaojia_Test=myParam" >> "$FLOW_ENV" を使用します。

ジョブ 1 では、[ステップの追加] > [ユーティリティ] > [変数の設定] に移動してステップを追加することで、環境変数をパイプラインレベルに昇格させることができます。
コンテナまたは VM 環境
ジョブ内での変数の受け渡し
このシナリオでは、単一のジョブ内で環境変数を共有します。たとえば、ステップ 1 で変数 yaojia_Test=myParam を生成し、ステップ 2 で ${yaojia_Test} を使用してそれを参照します。
前のステップで、コマンド echo "yaojia_Test=myParam" >> "$FLOW_ENV" を実行して変数を $FLOW_ENV ファイルに追記することで、環境変数を注入できます。
# ステップ 2 の実行ログ
echo $yaojia_Test
myParam
# [Success]
ジョブ間での変数の受け渡し
このシナリオでは、パイプライン内の複数のジョブ間で環境変数を共有します。たとえば、ジョブ 1 で変数 yaojia_Test=myParam を生成し、ジョブ 2 で ${yaojia_Test} を使用してそれを参照します。
-
ジョブ 1 のステップで、
$FLOW_ENVファイルに追記することで環境変数を注入します。 -
ジョブ 1 では、 を選択して別のステップを追加することで、環境変数をパイプラインレベルに昇格させます。
-
ジョブ 2 で、
${yaojia_Test}を使用して変数を参照できます。
ジョブ 1 で変数を注入して昇格させた後、ジョブ 2 で ${yaojia_Test}
# ジョブ 2 の実行ログ
echo $yaojia_Test
myParam
# [成功] を使用して参照できます。
コンテナまたは VM 環境の使用上の注意
-
上書きを防ぐための追記モードの使用 —
$FLOW_ENVに変数を書き込む際は、追記演算子 (>>) を使用してください。上書き演算子 (>) を使用すると、以前に書き込まれたすべての変数が置き換えられるため、使用しないでください。# 正しい例: 追記モードは既存の変数を保持 echo "VAR_A=value1" >> "$FLOW_ENV" echo "VAR_B=value2" >> "$FLOW_ENV" # 誤った例: 上書きモード - VAR_A が失われる echo "VAR_A=value1" > "$FLOW_ENV" echo "VAR_B=value2" > "$FLOW_ENV" -
同一ステップでの読み取り制限 —
echoを使用して$FLOW_ENVに変数を書き込んだ後、$KEYを参照して同じステップ内で変数をすぐに読み取ることはできません。変数は、現在のステップが終了した後にのみランタイムコンテキストに読み込まれます。変数の値を検証するには、後続のステップで読み取ってください。 -
Kubernetes デプロイの回避策 — シェルスクリプトステップで定義された変数が Kubernetes デプロイステップで利用できない、またはデフォルト値を返す場合は、シェルステップの後に [変数の設定] ステップ () を追加します。このステップでは、変数を、Kubernetes ステップが参照できる新しい変数名に明示的に割り当てます。
-
バージョン番号の動的な抽出 —
pom.xmlなどのビルド成果物からバージョン番号を抽出し、後続の Docker イメージビルドステップに渡すには:# pom.xml からバージョンを抽出 VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/') echo "IMAGE_VERSION=$VERSION" >> "$FLOW_ENV" -
変数設定の問題のトラブルシューティング — コンテナ環境で変数が有効にならない、またはエラーが発生する場合は、次の点を確認してください:
-
変数をパイプラインレベルに昇格させるために、[変数を設定] ステップを追加しました。
-
構文がターゲット環境と一致していること。コンテナまたは VM 環境では
echo "KEY=VALUE" >> "$FLOW_ENV"を使用してください。デフォルト環境専用のecho 'USER_KEY=VALUE' > .envは使用しないでください。
-
よくある質問
マルチ環境デプロイメントで環境変数を使用したり、ビルドターゲットを動的に選択したりするにはどうすればよいですか?
-
マルチ環境デプロイメント:開発、テスト、本番などのステージごとに個別のパイプラインを作成します。各パイプラインで、環境 ID や設定ファイルパスなど、ターゲット環境に固有のカスタム変数を設定します。この方法により、ビルドスクリプトを変更せずに、環境ごとにデプロイメントを分けられます。
-
ビルドターゲットの動的な選択:Alibaba Cloud DevOps Flow は、パイプライン UI から特定のビルドターゲット (特定の JAR ファイルやサービスモジュールなど) を選択することには対応していません。回避策として、ターゲットのサービスディレクトリパスを指定するランタイム選択変数を定義します。この変数をビルドコマンドで参照してビルドターゲットを動的に選択し、アーティファクトのアップロードパスには、選択した変数値に対応するディレクトリのみが含まれるように設定します。