CircleCIでの環境変数の設定方法と優先順位について

CircleCIでの環境変数の設定方法は複数あります。
今回は、複数ある環境変数の設定のやり方を確認し、環境変数名が被った際にどのやり方で設定した環境変数が優先されるかをまとめます。
(記事作成中に公式で良さげなまとまったページを見つけたので、基本的にそっちに誘導してまとめる感じにしてます。)

CircleCIとは

CI/CDサービス(ビルド・テスト・デプロイの自動化)の一つ。
GitHubとの連携がめちゃくちゃ簡単。
最近になって、GitHubが自社でCI/CDサービス(GitHub Actions)の提供を開始したので今後シェアがどうなるかわからないですが、まだまだCircleCIの方が高機能な印象。

環境変数の設定方法

シェルコマンドによる設定

こちらを参照

ステップ内での設定

こちらを参照

ジョブ内での設定

こちらを参照

コンテナ内での設定

こちらを参照

Context内での設定

Contextは、環境変数をプロジェクト間で共有するための仕組みです。
Organizationの下に複数、作成ができ、プロジェクトのconfig.ymlのworkflowsセクションで使うContextを指定することができます。
設定方法はこちらを参照

プロジェクト内での設定

こちらを参照

環境変数の優先順位

環境変数名が重複している場合、下記リストの上から順に優先されます。

• シェルコマンドによる設定
• ステップ内での設定
• ジョブ内での設定
• Context内での設定
• プロジェクト内での設定
• 組み込み環境変数
  • CircleCIで事前に組まれている環境変数。詳細はこちらを参照。

下記のように環境変数が設定されている場合を考えます。

環境変数名 / 設定方法	シェルコマンド	ステップ	ジョブ	Context	プロジェクト	組み込み
ENV_SAMPLE_1	1		3		5
ENV_SAMPLE_2			C	D
CI		false				true

ENV_SAMPLE_1は 1 、ENV_SAMPLE_2は C 、CIは false となります。

気になっていること

現在のContextの仕様では、1ワークフローに1つのContextしか指定することができないようです。
「Organization直下のプロジェクトには、すべてこの環境変数を提供したい」というシーンでは、複数作成されているContextすべてにその環境変数を設定する必要があります。
ワークフローに複数のContextを指定できるようにするか、Organizationにそのまま環境変数を設定できる仕組みを提供して欲しいなと思ったりしました。

ここらへんは、GitHub Actionsの方が使い勝手良い。
2020年5月に、Organization単位でSecrets(秘匿情報を含めた環境変数)を設定できるようになってます。

github.blog