¿Cómo Gitlab-CI hereda variables de entorno?

Las variables en Gitlab se pueden definir en varios lugares:

1. En la configuración de grupos
2. En la configuración del proyecto
3. Dentro de .gitlab-ci.yml

En este caso, las variables en la configuración de grupos y proyectos se pueden definir como 'archivo' o 'variable normal' y marcar las casillas 'protegido' y 'enmascarar'.

Comencemos con una herencia simple y se irá complicando gradualmente.

Se puede encontrar la lista completa de niveles de prioridad al final del documento.

Herencia con grupos [fuentes]

Las variables de los grupos se heredan con la regla de que cuanto más cerca esté el grupo del proyecto, más importante es su valor.

Grupos con variables

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

Resultado del pipeline

$ echo $MSG
B

Si la variable no se hubiera especificado en el grupo B, habríamos visto el valor A.

Herencia de variables dentro de .gitlab-ci.yml [fuentes]

Aquí todo es bastante simple: se puede definir una variable globalmente o se puede sobrescribir dentro del trabajo.

Grupos con variables

.gitlab-ci.yml

Ahora crearemos 2 trabajos, en uno de ellos especificaremos explícitamente $MSG.

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Personalizado en el .gitlab-ci.yml global"

echo:
  stage: test
  script:
    - echo $MSG

echo con var:
  stage: test
  variables:
    MSG: "Personalizado en el .gitlab-ci.yml del trabajo"
  script:
    - echo $MSG

Resultado del pipeline

• echo:

  $ echo $MSG
  Personalizado en el .gitlab-ci.yml global
  Trabajo exitoso

• echo con vars:

  $ echo $MSG
  Personalizado en el .gitlab-ci.yml del trabajo
  Trabajo exitoso

Herencia con grupos y dentro de .gitlab-ci.yml [fuentes]

Intentemos combinar los 2 ejemplos anteriores. Las variables de los grupos tienen prioridad sobre las variables dentro de .gitlab-ci.yml.

Grupos con variables

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Personalizado en el .gitlab-ci.yml global"

echo:
  stage: test
  script:
    - echo $MSG

echo con var:
  stage: test
  variables:
    MSG: "Personalizado en el .gitlab-ci.yml del trabajo"
  script:
    - echo $MSG

Resultado del pipeline

• echo:

  $ echo $MSG
  Y
  Trabajo exitoso

• echo con vars:

  $ echo $MSG
  Y
  Trabajo exitoso

Herencia con las variables especificadas en la configuración del proyecto [fuentes]

Las variables en la configuración del proyecto siempre tienen la máxima prioridad. Y las variables especificadas dentro de .gitlab-ci.yml no tienen ningún efecto.

Grupos con variables

Las variables de los grupos tienen menor prioridad.

.gitlab-ci.yml

Utilizaremos el archivo del ejemplo anterior. Aquí nuevamente hay variables especificadas dentro de .gitlab-ci.yml, pero las variables dentro de los grupos aún tienen prioridad sobre ellas.

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Personalizado en el .gitlab-ci.yml global"

echo:
  stage: test
  script:
    - echo $MSG

echo con var:
  stage: test
  variables:
    MSG: "Personalizado en el .gitlab-ci.yml del trabajo"
  script:
    - echo $MSG

Resultado del pipeline

• echo:

  $ echo $MSG
  project-3
  Trabajo exitoso

• echo con vars:

  $ echo $MSG
  project-3
  Trabajo exitoso

Herencia con valor vacío [fuentes]

Un valor vacío también es un valor
Un valor vacío no es Null

Grupos con variables

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none
  MSG: "Personalizado en el .gitlab-ci.yml global"

echo:
  stage: test
  script:
    - echo $MSG

echo con var:
  stage: test
  variables:
    MSG: "Personalizado en el .gitlab-ci.yml del trabajo"
  script:
    - echo $MSG

Resultado del pipeline

• echo:

  $ echo $MSG
  Trabajo exitoso

• echo con vars:

  $ echo $MSG
  Trabajo exitoso

Herencia con inclusión y grupos [fuentes]

Aquí intentaremos incluir project-3 en project-2
En este caso, los grupos tienen prioridad.

Grupos con variables

.gitlab-ci.yml

Y definiremos una variable globalmente en .gitlab-ci.yml

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

Resultado del pipeline

• echo:

  $ echo $MSG
  B
  Trabajo exitoso

• echo con vars:

  $ echo $MSG
  B
  Trabajo exitoso

Herencia con inclusión [fuentes]

Aquí intentaremos incluir project-3 en project-2.
Con la condición de que ni el grupo ni el propio proyecto tengan variables.

Grupos con variables

.gitlab-ci.yml

El mismo que en el ejemplo anterior

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

Resultado del pipeline

• echo:

  $ echo $MSG
  Con incluir .gitlab-ci.yml
  El trabajo se completó con éxito

• echo con vars:

  $ echo $MSG
  Personalizado en el .gitlab-ci.yml del trabajo
  Trabajo exitoso

Se obtienen los siguientes prioridades:

1. Variables en la configuración del proyecto
2. Variables en los grupos
3. Variables estrictamente especificadas dentro del trabajo (incluyendo archivos incluidos)
4. Variables globales dentro de .gitlab-ci.yml
5. Variables globales dentro de archivos incluidos

Conclusión

El aspecto menos obvio es que la regla «cuanto más cerca esté la variable del código, más importante es» funciona primero para grupos, y luego la misma regla se aplica a las variables dentro de .gitlab-ci.yml, pero solo bajo la condición de que las variables en los grupos no estén definidas.
Además, un punto importante es entender que el espacio global para el .gitlab-ci.yml principal e incluido es común. Y el archivo en el que se incluye tiene prioridad.

Fuente: habr.com