Як 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, ми побачили значення А.

Спадкування змінних усередині .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 with 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

• echo with 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

• echo with 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

• echo with 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

• echo with 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

• 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