Как Gitlab-CI наследява променливите на средата?

Променливите в Gitlab могат да бъдат зададени на няколко места:

1. В настройките на групата
2. В настройките на проекта
3. Вътре в .gitlab-ci.yml

В този случай променливите в настройките на групата и проекта могат да бъдат зададени като „файл“ или „обикновена променлива“ и да поставите отметка в квадратчетата „защитен“ и „маска“.

Нека започнем с простото наследяване и то постепенно ще стане по-сложно.

Окончателният списък с нива на приоритет може да бъде намерен в края на документа.

Наследяване с групи [източници]

Променливите от групите се наследяват, като важи правилото, че колкото по-близо е групата до проекта, толкова по-важна е нейната стойност.

Групи с променливи

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

Резултат от тръбопровода

$ echo $MSG
B

Ако променливата не беше посочена в група B, тогава щяхме да видим стойността A.

Наследяване на променливи в .gitlab-ci.yml [източници]

Тук всичко е съвсем просто: можете да зададете променлива глобално или можете да я презапишете вътре в заданието.

Групи с променливи

.gitlab-ci.yml

Нека сега създадем 2 задания, като в едно от тях изрично ще посочим $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

• ехо с променливи:

  $ 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

• ехо с променливи:

  $ 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

• ехо с променливи:

  $ 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

• ехо с променливи:

  $ echo $MSG
  Job succeeded

Наследяване с включване и групи [източници]

Тук ще се опитаме да включим проект-2 в проект-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

• ехо с променливи:

  $ echo $MSG
  B
  Job succeeded

Наследяване с вкл [източници]

Тук ще се опитаме да включим проект-2 в проект-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

• ехо с променливи:

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

Резултатите са следните приоритети:

1. Променливи в настройките на проекта
2. Променливи в групи
3. Променливи, строго определени в задания (включително включени файлове)
4. Глобални променливи в .gitlab-ci.yml
5. Глобални променливи във включените файлове

Заключение

Най-неочевидният момент е, че правилото „колкото по-близо до кода е дадена променлива, толкова по-важна е тя“ работи първо за групи, а след това същото правило за променливи в .gitlab-ci.yml, но само при условие че променливите в групите не са посочени.
След това важен момент е да се разбере, че глобалното пространство за основния и включен .gitlab-ci.yml е общо. И файлът, в който се извършва включването, има приоритет.

Източник: www.habr.com