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

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

1. Dans les paramètres du groupe
2. Dans les paramètres du projet
3. À l'intérieur de .gitlab-ci.yml

Dans ce cas, les variables dans les paramètres du groupe et du projet peuvent être définies comme « fichier » ou « variable régulière » et cocher les cases « protégé » et « masque ».

Commençons par un héritage simple et cela deviendra progressivement plus complexe.

La liste définitive des niveaux de priorité se trouve à la fin du document.

Héritage avec des groupes [sources]

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

Groupes avec 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'avait pas été spécifiée dans le groupe B, alors nous aurions vu la valeur A.

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

Tout est assez simple ici : vous pouvez définir une variable globalement, ou vous pouvez l'écraser dans le travail.

Groupes avec 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: "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

Résultat du pipeline

• écho:

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

• écho avec les variables :

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

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

Essayons de combiner les 2 exemples précédents. Les variables de groupe ont priorité sur les variables à l'intérieur de .gitlab-ci.yml.

Groupes avec variables

.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

Résultat du pipeline

• écho:

  $ echo $MSG
  Y
  Job succeeded

• écho avec les variables :

  $ echo $MSG
  Y
  Job succeeded

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

Les variables dans les paramètres du projet ont TOUJOURS la priorité la plus élevée ! Et les variables spécifiées dans .gitlab-ci.yml ne jouent aucun rôle.

Groupes avec variables

Les variables de groupe ont une priorité inférieure.

.gitlab-ci.yml

Utilisons le fichier de l'exemple précédent. Ici encore, des variables sont spécifiées dans .gitlab-ci.yml, mais les variables à l'intérieur des groupes ont toujours la priorité sur elles.

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

Résultat du pipeline

• écho:

  $ echo $MSG
  project-3
  Job succeeded

• écho avec les variables :

  $ echo $MSG
  project-3
  Job succeeded

Héritage avec valeur vide [sources]

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

Groupes avec variables

.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

Résultat du pipeline

• écho:

  $ echo $MSG
  Job succeeded

• écho avec les variables :

  $ echo $MSG
  Job succeeded

Héritage avec inclusion et groupes [sources]

Ici, nous allons essayer d'inclure le projet-2 dans le projet-3
Les groupes dans ce cas sont prioritaires.

Groupes avec variables

.gitlab-ci.yml

Et définissez la variable globalement dans .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'

Résultat du pipeline

• écho:

  $ echo $MSG
  B
  Job succeeded

• écho avec les variables :

  $ echo $MSG
  B
  Job succeeded

Héritage avec inclusion [sources]

Ici, nous allons essayer d'inclure le projet-2 dans le projet-3.
A condition que : ni les groupes ni le projet lui-même n'aient de variables.

Groupes avec variables

.gitlab-ci.yml

Idem que dans l'exemple précédent

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

Résultat du pipeline

• écho:

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

• écho avec les variables :

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

Les résultats sont les suivants les priorités:

1. Variables dans les paramètres du projet
2. Variables en groupes
3. Variables strictement spécifiées dans les jobs (y compris les fichiers inclus)
4. Variables globales dans .gitlab-ci.yml
5. Variables globales dans les fichiers inclus

Conclusion

Le point le moins évident est que la règle « plus une variable est proche du code, plus elle est importante » fonctionne d'abord pour les groupes, puis la même règle pour les variables à l'intérieur de .gitlab-ci.yml, mais uniquement sous la condition que les variables dans les groupes ne sont pas spécifiées.
Ensuite, un 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 a lieu est prioritaire.

Source: habr.com