Las variables de Gitlab se pueden establecer en varios lugares:

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

En este caso, las variables en la configuración de los grupos y el proyecto se pueden establecer como "archivo" o "variable ordinaria" y marque las casillas "protegido" y "máscara".

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

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

^[]

, , .

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

$ echo $MSG
B

B, .

.gitlab-ci.yml ^[]

: , .

c

.gitlab-ci.yml

2 , $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

• echo:

  
  

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

  
  

• echo with vars:

  
  

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

  
  

  ---

  
  

.gitlab-ci.yml ^[]

2 . .gitlab-ci.yml.

c

.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

• echo:

  
  

  $ echo $MSG
  Y
  Job succeeded

  
  

• echo with vars:

  
  

  $ echo $MSG
  Y
  Job succeeded

  
  

  ---

  
  

^[]

! , .gitlab-ci.yml .

c

.

.gitlab-ci.yml

. , , .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

• echo:

  
  

  $ echo $MSG
  project-3
  Job succeeded

  
  

• echo with vars:

  
  

  $ echo $MSG
  project-3
  Job succeeded

  
  

  ---

  
  

^[]

–
– Null

c

.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

• echo:

  
  

  $ echo $MSG
  Job succeeded

  
  

• echo with vars:

  
  

  $ echo $MSG
  Job succeeded

  
  

  ---

  
  

^[]

project-2 project-3
.

c

.gitlab-ci.yml

.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'

• echo:

  
  

  $ echo $MSG
  B
  Job succeeded

  
  

• echo with vars:

  
  

  $ echo $MSG
  B
  Job succeeded

  
  

  ---

  
  

^[]

project-2 project-3.
C : , .

c

.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'

• echo:

  
  

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

  
  

• echo with vars:

  
  

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

  
  

:

3. ( )
4. .gitlab-ci.yml

El punto más obvio es que la regla "cuanto más cerca esté la variable del código, más importante es" funciona primero para los grupos, y luego la misma regla para las variables dentro de .gitlab-ci.yml, pero solo con la condición de que las variables en los grupos no estén definidas. .
Además, un lugar importante es la comprensión de que el espacio global para el núcleo y el .gitlab-ci.yml excluido es común. Y el archivo en el que se produce la inclusión tiene prioridad.