W jaki sposób Gitlab-CI dziedziczy zmienne środowiskowe?

Zmienne w Gitlabie można ustawić w kilku miejscach:

1. W ustawieniach grupy
2. W ustawieniach projektu
3. Wewnątrz .gitlab-ci.yml

W takim przypadku zmienne w ustawieniach grupy i projektu można ustawić jako „plik” lub „zmienna zwykła” i zaznaczyć pola wyboru „chronione” i „maska”.

Zacznijmy od prostego dziedziczenia, które stopniowo stanie się bardziej złożone.

Ostateczną listę poziomów priorytetów można znaleźć na końcu dokumentu.

Dziedziczenie z grupami [źródła]

Zmienne z grup są dziedziczone, przy czym im bliżej projektu znajduje się grupa, tym ważniejsza jest jej wartość.

Grupy ze zmiennymi

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

Wynik rurociągu

$ echo $MSG
B

Gdyby zmienna nie została określona w grupie B, wówczas zobaczylibyśmy wartość A.

Dziedziczenie zmiennych wewnątrz .gitlab-ci.yml [źródła]

Tutaj wszystko jest dość proste: możesz ustawić zmienną globalnie lub możesz ją nadpisać wewnątrz zadania.

Grupy ze zmiennymi

.gitlab-ci.yml

Stwórzmy teraz 2 zadania, w jednym z nich wyraźnie wskażemy $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

Wynik rurociągu

• Echo:

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

• echo z vars:

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

Dziedziczenie z grupami i wewnątrz .gitlab-ci.yml [źródła]

Spróbujmy połączyć poprzednie 2 przykłady. Zmienne grupowe mają pierwszeństwo przed zmiennymi wewnątrz .gitlab-ci.yml.

Grupy ze zmiennymi

.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

Wynik rurociągu

• Echo:

  $ echo $MSG
  Y
  Job succeeded

• echo z vars:

  $ echo $MSG
  Y
  Job succeeded

Dziedziczenie z podaniem zmiennych w ustawieniach projektu [źródła]

Zmienne w ustawieniach projektu ZAWSZE mają najwyższy priorytet! Zmienne określone w pliku .gitlab-ci.yml nie odgrywają żadnej roli.

Grupy ze zmiennymi

Zmienne grupowe mają niższy priorytet.

.gitlab-ci.yml

Skorzystajmy z pliku z poprzedniego przykładu. Tutaj znowu istnieją zmienne określone wewnątrz .gitlab-ci.yml, ale zmienne wewnątrz grup nadal mają nad nimi pierwszeństwo.

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

Wynik rurociągu

• Echo:

  $ echo $MSG
  project-3
  Job succeeded

• echo z vars:

  $ echo $MSG
  project-3
  Job succeeded

Dziedziczenie z pustą wartością [źródła]

Pusta wartość jest również wartością
Pusta wartość nie jest równa Null

Grupy ze zmiennymi

.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

Wynik rurociągu

• Echo:

  $ echo $MSG
  Job succeeded

• echo z vars:

  $ echo $MSG
  Job succeeded

Dziedziczenie z uwzględnieniem i grupami [źródła]

Tutaj postaramy się włączyć projekt-2 do projektu-3
Grupy w tym przypadku mają pierwszeństwo.

Grupy ze zmiennymi

.gitlab-ci.yml

I ustaw zmienną globalnie w .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'

Wynik rurociągu

• Echo:

  $ echo $MSG
  B
  Job succeeded

• echo z vars:

  $ echo $MSG
  B
  Job succeeded

Dziedziczenie z uwzględnieniem [źródła]

Tutaj postaramy się włączyć projekt-2 do projektu-3.
Pod warunkiem, że: ani grupy, ani sam projekt nie mają żadnych zmiennych.

Grupy ze zmiennymi

.gitlab-ci.yml

Tak samo jak w poprzednim przykładzie

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

Wynik rurociągu

• Echo:

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

• echo z vars:

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

Wyniki są następujące priorytety:

1. Zmienne w ustawieniach projektu
2. Zmienne w grupach
3. Zmienne ściśle określone wewnątrz zadań (w tym dołączone pliki)
4. Zmienne globalne wewnątrz .gitlab-ci.yml
5. Zmienne globalne wewnątrz dołączonych plików

wniosek

Najbardziej nieoczywistym punktem jest to, że zasada „im bliżej kodu znajduje się zmienna, tym jest ważniejsza” działa najpierw dla grup, a następnie ta sama zasada dla zmiennych wewnątrz .gitlab-ci.yml, ale tylko pod warunkiem że zmienne w grupach nie są określone.
Następnie ważnym punktem jest zrozumienie, że globalna przestrzeń dla głównego i dołączonego pliku .gitlab-ci.yml jest wspólna. A plik, w którym następuje włączenie, ma pierwszeństwo.

Źródło: www.habr.com