Як Gitlab-CI атрымлівае ў спадчыну зменныя асяроддзі?

Зменныя ў Gitlab можна задаць у некалькіх месцах:

  1. У наладах груп
  2. У настройках праекта
  3. Унутры .gitlab-ci.yml

Пры гэтым зменныя ў наладах груп і праекту можна задаць як "файл" ці "звычайную зменную" і паставіць галачкі "абаронена" і "маскіраваць".

Як Gitlab-CI атрымлівае ў спадчыну зменныя асяроддзі?

Пачнём з простага ўспадкоўвання і будзе паступова ўскладняцца.

З канчатковым спісам узроўняў прыярытэтаў можна азнаёміцца ​​ў канцы дакумента.

Атрыманне ў спадчыну з групамі [зыходнікі]

Пераменныя з груп успадкоўваюцца, з тым правілам, што чым бліжэй група размешчана да праекту тым яе значэнне важней.

Групы са зменнымі

Як Gitlab-CI атрымлівае ў спадчыну зменныя асяроддзі?

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

Вынік пайлайна

$ echo $MSG
B

Калі б зменная не была пазначана ў групе B, то мы б убачылі значэнне А.

Успадкоўванне зменных усярэдзіне .gitlab-ci.yml [зыходнікі]

Тут усё даволі проста: можна задаць глабальна зменную, а можна перазапісаць яе ўсярэдзіне джобы.

Групы з зменнымі

Як Gitlab-CI атрымлівае ў спадчыну зменныя асяроддзі?

.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 with vars:
    $ echo $MSG
    Custom in job .gitlab-ci.yml
    Job succeeded

Атрыманне ў спадчыну з групамі і ўнутры .gitlab-ci.yml [зыходнікі]

Паспрабуем аб'яднаць папярэднія 2 прыклады. Пераменныя груп у прыярытэце перад зменнымі ўнутры .gitlab-ci.yml.

Групы з зменнымі

Як Gitlab-CI атрымлівае ў спадчыну зменныя асяроддзі?

.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 with vars:
    $ echo $MSG
    Y
    Job succeeded

Атрыманне ў спадчыну з указаннем зменных у наладах праекта [зыходнікі]

Зменныя ў наладах праекта маюць ЗАЎСЁДЫ найвышэйшы прыярытэт! І зменныя, паказаныя ўсярэдзіне .gitlab-ci.yml не гуляюць ніякай ролі.

Групы з зменнымі

Пераменныя групы маюць меншы прыярытэт.
Як Gitlab-CI атрымлівае ў спадчыну зменныя асяроддзі?

.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 with vars:
    $ echo $MSG
    project-3
    Job succeeded

Атрыманне ў спадчыну з пустым значэннем [зыходнікі]

Пустое значэнне - гэта таксама значэнне
Пустое значэнне - гэта не Null

Групы з зменнымі

Як Gitlab-CI атрымлівае ў спадчыну зменныя асяроддзі?

.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 with vars:
    $ echo $MSG
    Job succeeded

Атрыманне ў спадчыну з інклюдам і групамі [зыходнікі]

Тут паспрабуем у project-2 заінклюдзіць project-3
Групы ў дадзеным выпадку маюць прыярытэт.

Групы з зменнымі

Як Gitlab-CI атрымлівае ў спадчыну зменныя асяроддзі?

.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 with vars:
    $ echo $MSG
    B
    Job succeeded

Атрыманне ў спадчыну з інклюдам [зыходнікі]

Тут паспрабуем у project-2 заінклюдзіць project-3.
З умовай што: ні групы, ні сам праект не маюць ніякіх зменных.

Групы з зменнымі

Як Gitlab-CI атрымлівае ў спадчыну зменныя асяроддзі?

.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 with vars:
    $ echo $MSG
    Custom in job .gitlab-ci.yml
    Job succeeded

Атрымліваюцца наступныя прыярытэты:

  1. Зменныя ў настройках праекта
  2. Пераменныя ў групах
  3. Пераменныя строга паказаныя ўсярэдзіне джобы (у тым ліку і заінклюдзеныя файлы)
  4. Глабальныя зменныя ўсярэдзіне .gitlab-ci.yml
  5. Глабальныя зменныя ўсярэдзіне заінклюдаваных файлаў

Заключэнне

Самым не відавочным момантам з'яўляецца, што правіла «чым бліжэй зменная да кода, тым яна галоўней» працуе спачатку для груп, а затым такое ж правіла і для зменных усярэдзіне .gitlab-ci.yml, але толькі з умовай што зменныя ў групах не зададзены .
Далей важным месцам з'яўляецца разуменне таго, што глабальная прастора для асноўнага і заінклюдзенага .gitlab-ci.yml - агульнае. І той файл у які адбываецца інклюд мае прыярытэт.

Крыніца: habr.com

Дадаць каментар