Bagaimanakah Gitlab-CI mewarisi pembolehubah persekitaran?

Pembolehubah dalam Gitlab boleh ditetapkan di beberapa tempat:

  1. Dalam tetapan kumpulan
  2. Dalam tetapan projek
  3. Di dalam .gitlab-ci.yml

Dalam kes ini, pembolehubah dalam tetapan kumpulan dan projek boleh ditetapkan sebagai "fail" atau "pembolehubah biasa" dan tandakan kotak pilihan "dilindungi" dan "topeng".

Bagaimanakah Gitlab-CI mewarisi pembolehubah persekitaran?

Mari kita mulakan dengan pewarisan mudah dan ia akan beransur-ansur menjadi lebih kompleks.

Senarai akhir tahap keutamaan boleh didapati di penghujung dokumen.

Pewarisan bersama kumpulan [sumber]

Pembolehubah daripada kumpulan diwarisi, dengan peraturan bahawa semakin hampir kumpulan itu terletak dengan projek, semakin penting nilainya.

Kumpulan dengan pembolehubah

Bagaimanakah Gitlab-CI mewarisi pembolehubah persekitaran?

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

Hasil saluran paip

$ echo $MSG
B

Jika pembolehubah tidak dinyatakan dalam kumpulan B, maka kita akan melihat nilai A.

Mewarisi pembolehubah di dalam .gitlab-ci.yml [sumber]

Segala-galanya agak mudah di sini: anda boleh menetapkan pembolehubah secara global, atau anda boleh menulis gantinya di dalam kerja.

Kumpulan dengan pembolehubah

Bagaimanakah Gitlab-CI mewarisi pembolehubah persekitaran?

.gitlab-ci.yml

Sekarang mari kita cipta 2 pekerjaan, dalam salah satu daripadanya kita akan nyatakan $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

Hasil saluran paip

  • gema:
    $ echo $MSG
    Custom in global .gitlab-ci.yml
    Job succeeded
  • bergema dengan vars:
    $ echo $MSG
    Custom in job .gitlab-ci.yml
    Job succeeded

Warisan dengan kumpulan dan dalam .gitlab-ci.yml [sumber]

Cuba kita gabungkan 2 contoh sebelumnya. Pembolehubah kumpulan diutamakan berbanding pembolehubah dalam .gitlab-ci.yml.

Kumpulan dengan pembolehubah

Bagaimanakah Gitlab-CI mewarisi pembolehubah persekitaran?

.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

Hasil saluran paip

  • gema:
    $ echo $MSG
    Y
    Job succeeded
  • bergema dengan vars:
    $ echo $MSG
    Y
    Job succeeded

Warisan dengan menentukan pembolehubah dalam tetapan projek [sumber]

Pembolehubah dalam tetapan projek SENTIASA mempunyai keutamaan tertinggi! Dan pembolehubah yang dinyatakan di dalam .gitlab-ci.yml tidak memainkan sebarang peranan.

Kumpulan dengan pembolehubah

Pembolehubah kumpulan mempunyai keutamaan yang lebih rendah.
Bagaimanakah Gitlab-CI mewarisi pembolehubah persekitaran?

.gitlab-ci.yml

Mari gunakan fail dari contoh sebelumnya. Di sini sekali lagi terdapat pembolehubah yang dinyatakan dalam .gitlab-ci.yml, tetapi pembolehubah dalam kumpulan masih diutamakan daripada mereka.

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

Hasil saluran paip

  • gema:
    $ echo $MSG
    project-3
    Job succeeded
  • bergema dengan vars:
    $ echo $MSG
    project-3
    Job succeeded

Warisan dengan nilai kosong [sumber]

Nilai kosong juga merupakan nilai
Nilai kosong bukan Null

Kumpulan dengan pembolehubah

Bagaimanakah Gitlab-CI mewarisi pembolehubah persekitaran?

.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

Hasil saluran paip

  • gema:
    $ echo $MSG
    Job succeeded
  • bergema dengan vars:
    $ echo $MSG
    Job succeeded

Warisan dengan termasuk dan kumpulan [sumber]

Di sini kami akan cuba memasukkan projek-2 dalam projek-3
Kumpulan dalam kes ini mempunyai keutamaan.

Kumpulan dengan pembolehubah

Bagaimanakah Gitlab-CI mewarisi pembolehubah persekitaran?

.gitlab-ci.yml

Dan tetapkan pembolehubah secara global dalam .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'

Hasil saluran paip

  • gema:
    $ echo $MSG
    B
    Job succeeded
  • bergema dengan vars:
    $ echo $MSG
    B
    Job succeeded

Warisan dengan termasuk [sumber]

Di sini kami akan cuba memasukkan projek-2 dalam projek-3.
Dengan syarat bahawa: kumpulan mahupun projek itu sendiri tidak mempunyai sebarang pembolehubah.

Kumpulan dengan pembolehubah

Bagaimanakah Gitlab-CI mewarisi pembolehubah persekitaran?

.gitlab-ci.yml

Sama seperti contoh sebelumnya

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

Hasil saluran paip

  • gema:
    $ echo $MSG
    With include .gitlab-ci.yml
    Job succeeded
  • bergema dengan vars:
    $ echo $MSG
    Custom in job .gitlab-ci.yml
    Job succeeded

Hasilnya adalah seperti berikut keutamaan:

  1. Pembolehubah dalam tetapan projek
  2. Pembolehubah dalam kumpulan
  3. Pembolehubah dinyatakan dengan ketat dalam kerja (termasuk fail yang disertakan)
  4. Pembolehubah global di dalam .gitlab-ci.yml
  5. Pembolehubah global di dalam fail yang disertakan

Kesimpulan

Perkara yang paling tidak jelas ialah peraturan "semakin dekat pembolehubah dengan kod, semakin penting ia" berfungsi terlebih dahulu untuk kumpulan, dan kemudian peraturan yang sama untuk pembolehubah di dalam .gitlab-ci.yml, tetapi hanya di bawah syarat bahawa pembolehubah dalam kumpulan tidak dinyatakan .
Seterusnya, perkara penting ialah memahami bahawa ruang global untuk .gitlab-ci.yml utama dan disertakan adalah perkara biasa. Dan fail di mana kemasukan berlaku mempunyai keutamaan.

Sumber: www.habr.com

Tambah komen