🥇Como o Gitlab-CI herda variáveis de ambiente?

As variáveis no GitLab podem ser definidas em vários lugares:

Nas configurações de grupos
Nas configurações do projeto
Dentro do .gitlab-ci.yml

Nesse caso, as variáveis nas configurações de grupos e projetos podem ser definidas como "arquivo" ou "variável comum" e marcar as opções "protegido" e "mascarar".

Vamos começar com uma herança simples e gradualmente complicá-la.

A lista final de níveis de prioridade pode ser encontrada no final do documento.

Herdando com grupos [código-fonte]

As variáveis de grupos são herdadas, com a regra de que quanto mais próximo o grupo está do projeto, mais importante é seu valor.

Grupos com variáveis

.gitlab-ci.yml

image: busybox:latest
variables:
  GIT_STRATEGY: none

echo:
  stage: test
  script:
    - echo $MSG

Resultado do pipeline

$ echo $MSG
B

Se a variável não tivesse sido especificada no grupo B, teríamos visto o valor A.

Herdando variáveis dentro do .gitlab-ci.yml [código-fonte]

Aqui tudo é bastante simples: você pode definir uma variável globalmente ou pode sobrescrevê-la dentro do trabalho.

Grupos com variáveis

.gitlab-ci.yml

Agora, criaremos 2 trabalhos, em um dos quais especificaremos claramente $MSG.

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

echo:
  stage: test
  script:
    - echo $MSG

echo com var:
  stage: test
  variables:
    MSG: "Personalizado no trabalho .gitlab-ci.yml"
  script:
    - echo $MSG

Resultado do pipeline

echo:

$ echo $MSG
Personalizado no global .gitlab-ci.yml
Trabalho bem-sucedido

echo com vars:

$ echo $MSG
Personalizado no trabalho .gitlab-ci.yml
Trabalho bem-sucedido

Herdando com grupos e dentro do .gitlab-ci.yml [código-fonte]

Vamos tentar combinar os 2 exemplos anteriores. As variáveis de grupos têm prioridade sobre as variáveis dentro do .gitlab-ci.yml.

Grupos com variáveis

.gitlab-ci.yml

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

echo:
  stage: test
  script:
    - echo $MSG

echo com var:
  stage: test
  variables:
    MSG: "Personalizado no trabalho .gitlab-ci.yml"
  script:
    - echo $MSG

Resultado do pipeline

echo:
```
$ echo $MSG
Y
Trabalho bem-sucedido
```
echo com vars:
```
$ echo $MSG
Y
Trabalho bem-sucedido
```

Herdando com a definição de variáveis nas configurações do projeto [código-fonte]

As variáveis nas configurações do projeto sempre têm a mais alta prioridade! E as variáveis especificadas dentro do .gitlab-ci.yml não têm importância alguma.

Grupos com variáveis

As variáveis de grupos têm prioridade menor.

.gitlab-ci.yml

Vamos usar o arquivo do exemplo anterior. Aqui novamente existem variáveis especificadas dentro do .gitlab-ci.yml, mas as variáveis dentro dos grupos ainda têm prioridade sobre elas.

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

echo:
  stage: test
  script:
    - echo $MSG

echo com var:
  stage: test
  variables:
    MSG: "Personalizado no trabalho .gitlab-ci.yml"
  script:
    - echo $MSG

Resultado do pipeline

echo:

$ echo $MSG
project-3
Trabalho bem-sucedido

echo com vars:

$ echo $MSG
project-3
Trabalho bem-sucedido

Herdando com valor vazio [código-fonte]

Um valor vazio também é um valor
Um valor vazio não é Null

Grupos com variáveis

.gitlab-ci.yml

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

echo:
  stage: test
  script:
    - echo $MSG

echo com var:
  stage: test
  variables:
    MSG: "Personalizado no trabalho .gitlab-ci.yml"
  script:
    - echo $MSG

Resultado do pipeline

echo:
```
$ echo $MSG
Trabalho bem-sucedido
```
echo com vars:
```
$ echo $MSG
Trabalho bem-sucedido
```

Herdando com include e grupos [código-fonte]

Aqui vamos tentar incluir project-3 em project-2
Os grupos, nesse caso, têm prioridade.

Grupos com variáveis

.gitlab-ci.yml

E vamos definir uma variável globalmente no .gitlab-ci.yml

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

Resultado do pipeline

echo:
```
$ echo $MSG
B
Trabalho bem-sucedido
```
echo com vars:
```
$ echo $MSG
B
Trabalho bem-sucedido
```

Herdando com include [código-fonte]

Aqui vamos tentar incluir project-3 em project-2.
Com a condição de que: nem o grupo, nem o próprio projeto tenham variáveis.

Grupos com variáveis

.gitlab-ci.yml

Igual ao exemplo anterior

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

Resultado do pipeline

echo:

$ echo $MSG
Com include .gitlab-ci.yml
Trabalho concluído

echo com vars:

$ echo $MSG
Personalizado no trabalho .gitlab-ci.yml
Trabalho bem-sucedido

Resultam os seguintes prioridades:

Variáveis nas configurações do projeto
Variáveis nos grupos
Variáveis estritamente especificadas dentro do trabalho (incluindo arquivos incluídos)
Variáveis globais dentro do .gitlab-ci.yml
Variáveis globais dentro de arquivos incluídos

Conclusão

O ponto menos óbvio é que a regra "quanto mais próxima a variável do código, mais importante ela é" funciona primeiro para grupos, e depois a mesma regra se aplica para variáveis dentro do .gitlab-ci.yml, mas apenas sob a condição de que as variáveis nos grupos não estejam definidas.
Além disso, um ponto importante é entender que o espaço global para o principal e o incluído .gitlab-ci.yml é comum. E o arquivo em que ocorre a inclusão tem prioridade.

Fonte: habr.com