🥇Gitlab-CI は環境変数をどのように継承しますか?

Gitlab の変数はいくつかの場所で設定できます。

グループ設定で
プロジェクト設定で
.gitlab-ci.yml 内

この場合、グループおよびプロジェクト設定の変数を「ファイル」または「通常の変数」として設定し、「保護」および「マスク」チェックボックスをオンにします。

単純な継承から始めて、徐々に複雑になっていきます。

優先レベルの最終リストは、この文書の最後に記載されています。

グループによる継承 [出典]

グループの変数は、グループがプロジェクトに近いほどその値が重要になるというルールに従って継承されます。

変数を含むグループ

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

.gitlab-ci.yml 内の変数の継承 [出典]

ここではすべてが非常に簡単です。変数をグローバルに設定することも、ジョブ内で上書きすることもできます。

変数を含むグループ

.gitlab-ci.yml

ここで 2 つのジョブを作成しましょう。そのうちの XNUMX つでは $MSG を明示的に指定します。

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Custom in global .gitlab-ci.yml"

echo:
  stage: test
  script:
    - echo $MSG

echo with var:
  stage: test
  variables:
    MSG: "Custom in job .gitlab-ci.yml"
  script:
    - echo $MSG

パイプラインの結果

エコー：

$ echo $MSG
Custom in global .gitlab-ci.yml
Job succeeded

vars でエコーする:

$ echo $MSG
Custom in job .gitlab-ci.yml
Job succeeded

グループと .gitlab-ci.yml 内の継承 [出典]

前の 2 つの例を組み合わせてみましょう。グループ変数は、.gitlab-ci.yml 内の変数より優先されます。

変数を含むグループ

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Custom in global .gitlab-ci.yml"

echo:
  stage: test
  script:
    - echo $MSG

echo with var:
  stage: test
  variables:
    MSG: "Custom in job .gitlab-ci.yml"
  script:
    - echo $MSG

パイプラインの結果

エコー：
```
$ echo $MSG
Y
Job succeeded
```
vars でエコーする:
```
$ echo $MSG
Y
Job succeeded
```

プロジェクト設定で変数を指定して継承する [出典]

プロジェクト設定の変数は常に最優先されます。また、.gitlab-ci.yml 内で指定された変数は何の役割も果たしません。

変数を含むグループ

グループ変数の優先順位は低くなります。

.gitlab-ci.yml

前の例のファイルを使用してみましょう。ここでも .gitlab-ci.yml 内で指定された変数がありますが、グループ内の変数は依然としてそれらよりも優先されます。

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Custom in global .gitlab-ci.yml"

echo:
  stage: test
  script:
    - echo $MSG

echo with var:
  stage: test
  variables:
    MSG: "Custom in job .gitlab-ci.yml"
  script:
    - echo $MSG

パイプラインの結果

エコー：
```
$ echo $MSG
project-3
Job succeeded
```
vars でエコーする:
```
$ echo $MSG
project-3
Job succeeded
```

空の値による継承 [出典]

空の値も値です
空の値は Null ではありません

変数を含むグループ

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Custom in global .gitlab-ci.yml"

echo:
  stage: test
  script:
    - echo $MSG

echo with var:
  stage: test
  variables:
    MSG: "Custom in job .gitlab-ci.yml"
  script:
    - echo $MSG

パイプラインの結果

エコー：
```
$ echo $MSG
Job succeeded
```
vars でエコーする:
```
$ echo $MSG
Job succeeded
```

インクルードとグループによる継承 [出典]

ここでは、project-2 に project-3 を含めてみます。
この場合はグループが優先されます。

変数を含むグループ

.gitlab-ci.yml

そして変数を .gitlab-ci.yml でグローバルに設定します

variables:
 MSG: "With  include  .gitlab-ci.yml"
include:
 - project: how-is-gitlab-ci-inherit-environment-variables/z/y/project-3
   file: '.gitlab-ci.yml'

パイプラインの結果

エコー：
```
$ echo $MSG
B
Job succeeded
```
vars でエコーする:
```
$ echo $MSG
B
Job succeeded
```

インクルードを使用した継承 [出典]

ここでは、project-2 に project-3 を含めてみます。
ただし、グループにもプロジェクト自体にも変数がないことが条件です。

変数を含むグループ

.gitlab-ci.yml

前の例と同じ

variables:
 MSG: "With  include  .gitlab-ci.yml"
include:
 - project: how-is-gitlab-ci-inherit-environment-variables/z/y/project-3
   file: '.gitlab-ci.yml'

パイプラインの結果

エコー：

$ echo $MSG
With include .gitlab-ci.yml
Job succeeded

vars でエコーする:

$ echo $MSG
Custom in job .gitlab-ci.yml
Job succeeded

結果は次のとおりです優先順位:

プロジェクト設定の変数
グループ内の変数
ジョブ内で厳密に指定された変数（インクルードファイルを含む）
.gitlab-ci.yml 内のグローバル変数
インクルードされたファイル内のグローバル変数

まとめ

最も分かりにくい点は、「変数がコードに近いほど重要である」というルールが最初にグループに適用され、次に .gitlab-ci.yml 内の変数にも同じルールが適用されますが、これは次の条件下でのみ適用されることです。グループ内の変数が指定されていないこと。
次に重要な点は、メインの .gitlab-ci.yml と含まれる .gitlab-ci.yml のグローバル空間が共通であることを理解することです。そして、インクルードが発生したファイルが優先されます。

出所： habr.com

Gitlab-CI は環境変数をどのように継承しますか?

Gitlab の変数はいくつかの場所で設定できます。

グループによる継承 [出典]

変数を含むグループ

.gitlab-ci.yml 内の変数の継承 [出典]

変数を含むグループ

グループと .gitlab-ci.yml 内の継承 [出典]

変数を含むグループ

プロジェクト設定で変数を指定して継承する [出典]

変数を含むグループ

空の値による継承 [出典]

変数を含むグループ

インクルードとグループによる継承 [出典]

変数を含むグループ

インクルードを使用した継承 [出典]

変数を含むグループ

結果は次のとおりです 優先順位:

まとめ

コメントを追加します 返信をキャンセル

結果は次のとおりです優先順位:

コメントを追加します返信をキャンセル