A respeito de CI/CD (continuous integration/continuous
delivery), julgue o próximo item.
No trecho do arquivo .gitlab-ci.yml, utilizado no GitLab CI/CD para definir regras de execução de pipelines com base em variáveis de ambiente, na execução do bloco job2, o valor da variável ALL_JOBS_VAR será “Different value than default”, pois variáveis definidas no nível do job têm precedência sobre as globais com o mesmo nome.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoC — Certo
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Precedência de variáveis no GitLab CI/CD
Gabarito: Certo (C). A afirmativa está correta porque, no GitLab CI/CD, variáveis definidas no nível do job têm precedência sobre variáveis globais com o mesmo nome, conforme a hierarquia de escopo da ferramenta. Assim, na execução do bloco job2, o valor de ALL_JOBS_VAR será o definido no próprio job, ou seja, "Different value than default".
O GitLab CI/CD é uma ferramenta de integração contínua e entrega contínua que permite automatizar o processo de build, teste e deploy de software por meio de pipelines definidos em arquivos .gitlab-ci.yml. Nesse contexto, as variáveis de ambiente desempenham um papel crucial, permitindo que valores sejam configurados em diferentes níveis de escopo: global, de pipeline, de job e até mesmo de runner. A precedência entre esses níveis é um conceito fundamental para entender como os pipelines se comportam.
A hierarquia de precedência de variáveis no GitLab CI/CD, da maior para a menor prioridade, é a seguinte: variáveis definidas no nível do job têm prioridade sobre as variáveis globais; variáveis definidas no nível do pipeline têm prioridade sobre as globais, mas são sobrepostas pelas do job; e as variáveis globais têm a menor prioridade entre os níveis de configuração do arquivo. Essa regra é essencial para permitir que cada job possa ter configurações específicas, sobrescrevendo valores padrão definidos globalmente.
Na prática, imagine um arquivo .gitlab-ci.yml com uma variável global ALL_JOBS_VAR: "default value" e um job job2 que redefine essa mesma variável com ALL_JOBS_VAR: "Different value than default". Quando o job2 é executado, o GitLab CI/CD resolve o valor da variável ALL_JOBS_VAR para o escopo mais específico, ou seja, o valor definido no próprio job. Portanto, dentro do job2, a variável terá o valor "Different value than default", exatamente como afirma a questão.
A pegadinha que a banca explora aqui é a confusão entre os níveis de escopo. Muitos candidatos podem pensar que a variável global prevalece, ou que há um erro de sintaxe, mas a regra de precedência é clara: o escopo mais específico (job) sobrescreve o mais genérico (global). Essa é uma característica comum em ferramentas de CI/CD, como Jenkins, GitHub Actions e GitLab CI, onde a configuração local tem prioridade sobre a configuração global.
Guarde a hierarquia de precedência: job > pipeline > global. É exatamente nessa ordem que as variáveis são resolvidas, e é nela que as alternativas desta questão se dividem.
Precedência de variáveis no GitLab CI/CD: Escopos (maior → menor prioridade) (Job, Pipeline, Global); Regra (Escopo mais específico sobrescreve o mais genérico); Efeito prático (Variável global redefinida no job, Job usa o valor local)
Item — ✅ CERTO
A afirmativa está correta. No GitLab CI/CD, variáveis definidas no nível do job têm precedência sobre variáveis globais com o mesmo nome. Isso significa que, quando um job define uma variável que também existe no nível global, o valor utilizado durante a execução do job será o definido no próprio job. Portanto, na execução do bloco job2, o valor de ALL_JOBS_VAR será "Different value than default", pois essa é a definição local do job, que sobrescreve a definição global.
PEGA ESSA DICA!
Para questões sobre precedência de variáveis em CI/CD, lembre-se da hierarquia: job > pipeline > global. Se a questão mencionar variáveis definidas em diferentes níveis, o valor que prevalece é sempre o do escopo mais específico. Essa regra é válida para o GitLab CI e, com pequenas variações, para outras ferramentas como GitHub Actions e Jenkins.
