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

Las variables en Gitlab se pueden configurar en varios lugares:

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

En este caso, las variables en la configuración del grupo y del proyecto se pueden configurar como "archivo" o "variable normal" y marcar las casillas de verificación "protegidas" y "máscara".

Comencemos con una herencia simple y gradualmente se irá volviendo más compleja.

La lista final de niveles de prioridad se puede encontrar 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 será su valor.

Grupos con variables

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

Resultado de la canalización

$ echo $MSG
B

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

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

Aquí todo es bastante simple: puedes configurar una variable globalmente o puedes sobrescribirla dentro del trabajo.

Grupos con variables

.gitlab-ci.yml

Creemos ahora 2 trabajos, en uno de ellos indicaremos explícitamente $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

Resultado de la canalización

• eco:

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

• eco con vars:

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

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

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

Grupos con 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

Resultado de la canalización

• eco:

  $ echo $MSG
  Y
  Job succeeded

• eco con vars:

  $ echo $MSG
  Y
  Job succeeded

Herencia con especificación de variables 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 juegan ningún papel.

Grupos con variables

Las variables de grupo tienen menor prioridad.

.gitlab-ci.yml

Usemos 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: "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

Resultado de la canalización

• eco:

  $ echo $MSG
  project-3
  Job succeeded

• eco con vars:

  $ echo $MSG
  project-3
  Job succeeded

Herencia con valor vacío [fuentes]

Un valor vacío también es un valor.
Un valor vacío no es nulo

Grupos con 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

Resultado de la canalización

• eco:

  $ echo $MSG
  Job succeeded

• eco con vars:

  $ echo $MSG
  Job succeeded

Herencia con inclusión y grupos. [fuentes]

Aquí intentaremos incluir el proyecto-2 en el proyecto-3.
Los grupos en este caso tienen prioridad.

Grupos con variables

.gitlab-ci.yml

Y configure la variable globalmente 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'

Resultado de la canalización

• eco:

  $ echo $MSG
  B
  Job succeeded

• eco con vars:

  $ echo $MSG
  B
  Job succeeded

Herencia con inclusión [fuentes]

Aquí intentaremos incluir el proyecto-2 en el proyecto-3.
Con la condición de que: ni los grupos ni el proyecto en sí tengan variables.

Grupos con variables

.gitlab-ci.yml

Igual que en el ejemplo anterior

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

Resultado de la canalización

• eco:

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

• eco con vars:

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

Los resultados son los siguientes prioridades:

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

Conclusión

El punto menos obvio es que la regla "cuanto más cerca está una variable del código, más importante es" funciona primero para grupos, y luego la misma regla para variables dentro de .gitlab-ci.yml, pero solo bajo la condición que las variables en los grupos no están especificadas.
A continuación, un punto importante es comprender que el espacio global para el .gitlab-ci.yml principal e incluido es común. Y tiene prioridad el fichero en el que se produce la inclusión.

Fuente: habr.com