As variáveis ​​do Gitlab podem ser definidas em vários locais:

1. Nas configurações de grupo
2. Nas configurações do projeto
3. Por dentro .gitlab-ci.yml

Nesse caso, as variáveis ​​nas configurações dos grupos e do projeto podem ser definidas como "arquivo" ou "variável comum" e marque as caixas "protegido" e "mascarar".

Vamos começar com uma herança simples e gradualmente se tornará mais complexa.

Uma lista final de níveis de prioridade pode ser encontrada no final do 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

O ponto mais óbvio é que a regra "quanto mais próxima a variável do código, mais importante ela é" funciona primeiro para grupos e, em seguida, a mesma regra para variáveis ​​dentro de .gitlab-ci.yml, mas apenas com a condição de que as variáveis ​​nos grupos não sejam definidas .
Além disso, um lugar importante é o entendimento de que o espaço global para o núcleo e o .gitlab-ci.yml excluído é comum. E o arquivo no qual a inclusão ocorre tem precedência.