🥇Comment Gitlab-CI hérite-t-il des variables d'environnement ?

Les variables dans GitLab peuvent être définies à plusieurs endroits :

Dans les paramètres de groupe
Dans les paramètres du projet
Dans le fichier .gitlab-ci.yml

Dans ce cas, les variables dans les paramètres de groupe et de projet peuvent être définies comme "fichier" ou "variable normale" et vous pouvez cocher les options "protégé" et "masqué".

Commençons par l'héritage simple et compliquons progressivement.

La liste finale des niveaux de priorité peut être consultée à la fin du document.

Héritage avec des groupes [sources]

Les variables des groupes sont héritées, avec la règle que plus le groupe est proche du projet, plus sa valeur est importante.

Groupes avec des variables

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

Résultat du pipeline

$ echo $MSG
B

Si la variable n'était pas spécifiée dans le groupe B, nous aurions vu la valeur A.

Héritage des variables dans le .gitlab-ci.yml [sources]

Ici, c'est assez simple : on peut définir une variable globalement ou la réécrire à l'intérieur d'un job.

Groupes avec des variables

.gitlab-ci.yml

Créons maintenant 2 jobs, dans l'un d'eux nous indiquerons explicitement $MSG.

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Personnalisé dans le .gitlab-ci.yml global"

echo:
  stage: test
  script:
    - echo $MSG

echo avec var:
  stage: test
  variables:
    MSG: "Personnalisé dans le job .gitlab-ci.yml"
  script:
    - echo $MSG

Résultat du pipeline

echo:

$ echo $MSG
Personnalisé dans le .gitlab-ci.yml global
Job réussi

echo avec vars:

$ echo $MSG
Personnalisé dans le job .gitlab-ci.yml
Job réussi

Héritage avec des groupes et à l'intérieur du .gitlab-ci.yml [sources]

Essayons de combiner les 2 exemples précédents. Les variables de groupe sont prioritaires par rapport aux variables à l'intérieur du .gitlab-ci.yml.

Groupes avec des variables

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Personnalisé dans le .gitlab-ci.yml global"

echo:
  stage: test
  script:
    - echo $MSG

echo avec var:
  stage: test
  variables:
    MSG: "Personnalisé dans le job .gitlab-ci.yml"
  script:
    - echo $MSG

Résultat du pipeline

echo:
```
$ echo $MSG
Y
Job réussi
```
echo avec vars:
```
$ echo $MSG
Y
Job réussi
```

Héritage avec spécification des variables dans les paramètres de projet [sources]

Les variables dans les paramètres du projet ont TOUJOURS la priorité la plus élevée ! Et les variables spécifiées à l'intérieur du .gitlab-ci.yml n'ont aucun rôle.

Groupes avec des variables

Les variables de groupe ont une priorité moindre.

Utilisons le fichier de l'exemple précédent. Ici encore, il y a des variables spécifiées à l'intérieur du .gitlab-ci.yml, mais les variables au sein des groupes ont tout de même la priorité sur elles.

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Personnalisé dans le .gitlab-ci.yml global"

echo:
  stage: test
  script:
    - echo $MSG

echo avec var:
  stage: test
  variables:
    MSG: "Personnalisé dans le job .gitlab-ci.yml"
  script:
    - echo $MSG

Résultat du pipeline

echo:
```
$ echo $MSG
projet-3
Job réussi
```
echo avec vars:
```
$ echo $MSG
projet-3
Job réussi
```

Héritage avec une valeur vide [sources]

Une valeur vide est aussi une valeur
Une valeur vide n'est pas Null

Groupes avec des variables

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Personnalisé dans le .gitlab-ci.yml global"

echo:
  stage: test
  script:
    - echo $MSG

echo avec var:
  stage: test
  variables:
    MSG: "Personnalisé dans le job .gitlab-ci.yml"
  script:
    - echo $MSG

Résultat du pipeline

echo:
```
$ echo $MSG
Job réussi
```
echo avec vars:
```
$ echo $MSG
Job réussi
```

Héritage avec inclusion et groupes [sources]

Ici, nous allons essayer d'inclure project-3 dans project-2
Les groupes ont ici la priorité.

Groupes avec des variables

.gitlab-ci.yml

Et définissons une variable globalement dans le .gitlab-ci.yml

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

Résultat du pipeline

echo:
```
$ echo $MSG
B
Job réussi
```
echo avec vars:
```
$ echo $MSG
B
Job réussi
```

Héritage avec inclusion [sources]

Ici, nous allons essayer d'inclure project-3 dans project-2.
À condition que ni le groupe ni le projet eux-mêmes n'aient de variables.

Groupes avec des variables

.gitlab-ci.yml

Identique à l'exemple précédent

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

Résultat du pipeline

echo:

$ echo $MSG
Avec include .gitlab-ci.yml
Travail réussi

echo avec vars:

$ echo $MSG
Personnalisé dans le job .gitlab-ci.yml
Job réussi

On obtient les suivants priorités:

Variables dans les paramètres du projet
Variables dans les groupes
Variables strictement spécifiées à l'intérieur de l'emploi (y compris les fichiers inclus)
Variables globales à l'intérieur de .gitlab-ci.yml
Variables globales à l'intérieur des fichiers inclus

Conclusion

Le point le moins évident est que la règle « plus la variable est proche du code, plus elle est importante » s'applique d'abord aux groupes, puis la même règle s'applique aux variables à l'intérieur de .gitlab-ci.yml, mais seulement à condition que les variables dans les groupes ne soient pas définies.
Un autre point important est de comprendre que l'espace global pour le .gitlab-ci.yml principal et inclus est commun. Et le fichier dans lequel l'inclusion se produit a la priorité.

Source : habr.com