🥇Come GitLab-CI eredita le variabili di ambiente?

Le variabili in Gitlab possono essere definite in diversi luoghi:

Nelle impostazioni del gruppo
Nelle impostazioni del progetto
All'interno di .gitlab-ci.yml

Inoltre, le variabili nelle impostazioni di gruppo e progetto possono essere definite come "file" o "variabile normale" e si possono selezionare le opzioni "protetta" e "maschera".

Partiamo dall'ereditarietà semplice e progrediamo verso strutture più complesse.

Un elenco finale dei livelli di priorità è disponibile alla fine del documento.

Ereditarietà con i gruppi [source]

Le variabili dai gruppi vengono ereditate, secondo la regola che più un gruppo è vicino al progetto, maggiore è la sua importanza.

Gruppi con variabili

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

Risultato del pipeline

$ echo $MSG
B

Se la variabile non fosse stata specificata nel gruppo B, avremmo visto il valore A.

Ereditarietà delle variabili all'interno di .gitlab-ci.yml [source]

Qui è abbastanza semplice: è possibile definire globalmente una variabile o sovrascriverla all'interno di un job.

Gruppi con variabili

.gitlab-ci.yml

Creiamo ora 2 job, in uno dei quali specificheremo esplicitamente $MSG.

immagine: busybox:latest
variabili:
  GIT_STRATEGY: none
  MSG: "Personalizzato in .gitlab-ci.yml globale"

echo:
  fase: test
  script:
    - echo $MSG

echo con var:
  fase: test
  variabili:
    MSG: "Personalizzato in .gitlab-ci.yml del lavoro"
  script:
    - echo $MSG

Risultato del pipeline

echo:

$ echo $MSG
Personalizzato in .gitlab-ci.yml globale
Lavoro riuscito

echo con vars:

$ echo $MSG
Personalizzato in .gitlab-ci.yml del lavoro
Lavoro riuscito

Ereditarietà con gruppi e all'interno di .gitlab-ci.yml [source]

Proviamo a combinare i due esempi precedenti. Le variabili di gruppo hanno la priorità sulle variabili all'interno di .gitlab-ci.yml.

Gruppi con variabili

.gitlab-ci.yml

immagine: busybox:latest
variabili:
  GIT_STRATEGY: none
  MSG: "Personalizzato in .gitlab-ci.yml globale"

echo:
  fase: test
  script:
    - echo $MSG

echo con var:
  fase: test
  variabili:
    MSG: "Personalizzato in .gitlab-ci.yml del lavoro"
  script:
    - echo $MSG

Risultato del pipeline

echo:
```
$ echo $MSG
Y
Lavoro riuscito
```
echo con vars:
```
$ echo $MSG
Y
Lavoro riuscito
```

Ereditarietà con variabili definite nelle impostazioni del progetto [source]

Le variabili nelle impostazioni del progetto hanno SEMPRE la massima priorità! E le variabili definite all'interno di .gitlab-ci.yml non hanno alcun ruolo.

Gruppi con variabili

Le variabili di gruppo hanno una priorità inferiore.

.gitlab-ci.yml

Utilizziamo il file dell'esempio precedente. Qui ci sono ancora variabili definite all'interno di .gitlab-ci.yml, ma le variabili all'interno dei gruppi hanno comunque priorità su di esse.

immagine: busybox:latest
variabili:
  GIT_STRATEGY: none
  MSG: "Personalizzato in .gitlab-ci.yml globale"

echo:
  fase: test
  script:
    - echo $MSG

echo con var:
  fase: test
  variabili:
    MSG: "Personalizzato in .gitlab-ci.yml del lavoro"
  script:
    - echo $MSG

Risultato del pipeline

echo:
```
$ echo $MSG
project-3
Lavoro riuscito
```
echo con vars:
```
$ echo $MSG
project-3
Lavoro riuscito
```

Ereditarietà con valore vuoto [source]

Un valore vuoto è comunque un valore
Un valore vuoto non è Null

Gruppi con variabili

.gitlab-ci.yml

immagine: busybox:latest
variabili:
  GIT_STRATEGY: none
  MSG: "Personalizzato in .gitlab-ci.yml globale"

echo:
  fase: test
  script:
    - echo $MSG

echo con var:
  fase: test
  variabili:
    MSG: "Personalizzato in .gitlab-ci.yml del lavoro"
  script:
    - echo $MSG

Risultato del pipeline

echo:
```
$ echo $MSG
Lavoro riuscito
```
echo con vars:
```
$ echo $MSG
Lavoro riuscito
```

Ereditarietà con include e gruppi [source]

Qui proviamo a includere project-3 in project-2
I gruppi in questo caso hanno la priorità.

Gruppi con variabili

.gitlab-ci.yml

E definiamo una variabile a livello globale in .gitlab-ci.yml

variabili:
 MSG: "Con include .gitlab-ci.yml"
included:
 - progetto: come-gitlab-ci-ereditare-variabili-ambiente/z/y/progetto-3
   file: '.gitlab-ci.yml'

Risultato del pipeline

echo:
```
$ echo $MSG
B
Job riuscito
```
echo con vars:
```
$ echo $MSG
B
Job riuscito
```

Ereditarietà con inclusione [source]

Qui proveremo a includere project-3 in project-2.
A condizione che: né il gruppo né il progetto stesso abbiano variabili.

Gruppi con variabili

.gitlab-ci.yml

Fatto come nell'esempio precedente

variabili:
 MSG: "Con include .gitlab-ci.yml"
included:
 - progetto: come-gitlab-ci-ereditare-variabili-ambiente/z/y/progetto-3
   file: '.gitlab-ci.yml'

Risultato del pipeline

echo:

$ echo $MSG
Con include .gitlab-ci.yml
Job riuscito

echo con vars:

$ echo $MSG
Personalizzato in .gitlab-ci.yml del lavoro
Lavoro riuscito

Otteniamo i seguenti priorità:

Variabili nelle impostazioni del progetto
Variabili nei gruppi
Variabili specificamente indicate all'interno del lavoro (comprese le file incluse)
Variabili globali all'interno di .gitlab-ci.yml
Variabili globali all'interno dei file inclusi

Conclusione

Il punto meno ovvio è che la regola 'più è vicina la variabile al codice, più è importante' funziona prima per i gruppi, e poi la stessa regola vale per le variabili all'interno di .gitlab-ci.yml, ma solo a condizione che le variabili nei gruppi non siano definite.
Un altro punto importante è comprendere che lo spazio globale per il principale e per il .gitlab-ci.yml incluso è comune. E il file in cui avviene l'inclusione ha la priorità.

Fonte: habr.com