Kiel Gitlab-CI heredas mediajn variablojn?

Variabloj en Gitlab povas esti agorditaj en pluraj lokoj:

1. En grupaj agordoj
2. En la agordoj de la projekto
3. Ene de .gitlab-ci.yml

En ĉi tiu kazo, variabloj en la grupo kaj projekto agordoj povas esti agordita kiel "dosiero" aŭ "regula variablo" kaj kontroli la "protektita" kaj "masko" markobutonoj.

Ni komencu per simpla heredo kaj ĝi iom post iom fariĝos pli kompleksa.

La fina listo de prioritataj niveloj troviĝas ĉe la fino de la dokumento.

Heredo kun grupoj [fontoj]

Variabloj de grupoj estas hereditaj, kun la regulo, ke ju pli proksime la grupo troviĝas al la projekto, des pli gravas ĝia valoro.

Grupoj kun variabloj

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

Dukto rezulto

$ echo $MSG
B

Se la variablo ne estus specifita en grupo B, tiam ni vidus la valoron A.

Heredante variablojn ene de .gitlab-ci.yml [fontoj]

Ĉio estas sufiĉe simpla ĉi tie: vi povas agordi variablon tutmonde, aŭ vi povas anstataŭigi ĝin ene de la laboro.

Grupoj kun variabloj

.gitlab-ci.yml

Ni nun kreu 2 laborpostenojn, en unu el ili ni eksplicite indikos $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

Dukto rezulto

• eĥo:

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

• eĥo kun vars:

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

Heredo kun grupoj kaj ene de .gitlab-ci.yml [fontoj]

Ni provu kombini la antaŭajn 2 ekzemplojn. Grupaj variabloj havas prioritaton super variabloj ene de .gitlab-ci.yml.

Grupoj kun variabloj

.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

Dukto rezulto

• eĥo:

  $ echo $MSG
  Y
  Job succeeded

• eĥo kun vars:

  $ echo $MSG
  Y
  Job succeeded

Heredo kun specifado de variabloj en projektaj agordoj [fontoj]

Variabloj en projektaj agordoj ĈIAM havas la plej altan prioritaton! Kaj la variabloj specifitaj ene de .gitlab-ci.yml ne ludas neniun rolon.

Grupoj kun variabloj

Grupvariabloj havas pli malaltan prioritaton.

.gitlab-ci.yml

Ni uzu la dosieron de la antaŭa ekzemplo. Ĉi tie denove estas variabloj specifitaj ene de .gitlab-ci.yml, sed variabloj ene de grupoj ankoraŭ havas prioritaton super ili.

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

Dukto rezulto

• eĥo:

  $ echo $MSG
  project-3
  Job succeeded

• eĥo kun vars:

  $ echo $MSG
  project-3
  Job succeeded

Heredaĵo kun malplena valoro [fontoj]

Malplena valoro ankaŭ estas valoro
Malplena valoro ne estas Nula

Grupoj kun variabloj

.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

Dukto rezulto

• eĥo:

  $ echo $MSG
  Job succeeded

• eĥo kun vars:

  $ echo $MSG
  Job succeeded

Heredo kun inkluzivi kaj grupoj [fontoj]

Ĉi tie ni provos inkluzivi projekto-2 en projekto-3
Grupoj en ĉi tiu kazo havas prioritaton.

Grupoj kun variabloj

.gitlab-ci.yml

Kaj starigu la variablon tutmonde en .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'

Dukto rezulto

• eĥo:

  $ echo $MSG
  B
  Job succeeded

• eĥo kun vars:

  $ echo $MSG
  B
  Job succeeded

Heredaĵo kun inkluzivi [fontoj]

Ĉi tie ni provos inkluzivi projekto-2 en projekto-3.
Kun la kondiĉo ke: nek la grupoj nek la projekto mem havas ajnajn variablojn.

Grupoj kun variabloj

.gitlab-ci.yml

Same kiel en la antaŭa ekzemplo

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

Dukto rezulto

• eĥo:

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

• eĥo kun vars:

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

La rezultoj estas kiel sekvas prioritatoj:

1. Variabloj en projektaj agordoj
2. Variabloj en grupoj
3. Variabloj strikte specifitaj ene de laboroj (inkluzive de inkluzivitaj dosieroj)
4. Tutmondaj variabloj ene de .gitlab-ci.yml
5. Tutmondaj variabloj ene inkludis dosierojn

konkludo

La plej ne evidenta punkto estas, ke la regulo "ju pli proksima variablo estas al la kodo, des pli grava ĝi estas" funkcias unue por grupoj, kaj poste la sama regulo por variabloj ene de .gitlab-ci.yml, sed nur sub la kondiĉo. ke la variabloj en la grupoj ne estas specifitaj.
Poste, grava punkto estas kompreni, ke la tutmonda spaco por la ĉefa kaj inkluzivita .gitlab-ci.yml estas ofta. Kaj la dosiero en kiu okazas la inkludo havas prioritaton.

fonto: www.habr.com