GitLab CI/CD: Pipelines Parent-Child e Multi-Project
Gabarito: letra A. O job microservico_A dispara um novo pipeline do tipo parent-child, pois a configuração no .gitlab-ci.yml utiliza a palavra-chave trigger com um arquivo de configuração local (referenciado por caminho relativo), o que caracteriza a criação de um pipeline filho a partir do pipeline pai. A alternativa correta é a letra A.
Para entender a questão, é preciso dominar os dois mecanismos de orquestração de pipelines no GitLab CI/CD: parent-child pipelines e multi-project pipelines. Ambos permitem que um pipeline dispare outro, mas a diferença crucial está em onde o pipeline disparado é definido e como ele é referenciado.
Parent-child pipelines (pipelines pai-filho) são usados quando você quer dividir um pipeline grande em vários pipelines menores, todos dentro do mesmo projeto. O pipeline pai usa a palavra-chave trigger com um caminho para um arquivo de configuração YAML dentro do próprio repositório (ex.: trigger: path/to/child.yml). O pipeline filho é executado como parte do mesmo projeto, mas com seu próprio conjunto de jobs e estágios. Isso é útil para melhorar a legibilidade, o desempenho e a manutenção de pipelines complexos.
Multi-project pipelines (pipelines multi-projeto), por outro lado, são usados para disparar um pipeline em um projeto diferente. O pipeline de um projeto usa a palavra-chave trigger com a referência a outro projeto (ex.: trigger: my-group/my-project). Isso permite criar pipelines que dependem de builds, testes ou deploys de outros projetos, estabelecendo uma relação de dependência entre eles.
A pegadinha da questão está em confundir esses dois conceitos. A banca explora exatamente a diferença entre referenciar um arquivo local (parent-child) e referenciar um projeto externo (multi-project). No caso do enunciado, o job microservico_A referencia um arquivo de configuração local, o que configura um pipeline parent-child. Como há apenas uma referência a um arquivo local, apenas um pipeline filho é criado.
Para fixar:
Critério | Parent-Child | Multi-Project |
|---|
Onde o pipeline disparado é definido | No mesmo projeto | Em outro projeto |
Como é referenciado | Por caminho de arquivo local (ex.: path/to/child.yml) | Por referência ao projeto (ex.: group/project) |
Relação entre pipelines | Pai e filho (hierarquia) | Projetos distintos (dependência) |
Uso típico | Dividir pipeline complexo em partes menores | Orquestrar pipelines entre projetos |
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa está correta porque o job microservico_A dispara um novo pipeline do tipo parent-child. A configuração usa a palavra-chave trigger com um caminho para um arquivo de configuração local (dentro do mesmo projeto), o que é a definição exata de um pipeline pai-filho. Como há apenas uma referência a um arquivo local, apenas um pipeline filho é criado.
Alternativa B — ❌ Incorreta
A alternativa está incorreta porque o pipeline disparado não é do tipo multi-project. O multi-project é caracterizado por referenciar um projeto externo (ex.: trigger: group/project), e não um arquivo local. A configuração apresentada no enunciado referencia um arquivo de configuração dentro do mesmo projeto, o que configura um parent-child, não um multi-project.
Alternativa C — ❌ Incorreta
A alternativa está incorreta porque afirma que são disparados dois pipelines parent-child. A configuração apresentada contém apenas uma referência a um arquivo de configuração local, portanto apenas um pipeline filho é criado. Não há duas referências a arquivos locais no job microservico_A.
Alternativa D — ❌ Incorreta
A alternativa está incorreta porque afirma que são disparados dois pipelines multi-project. Além de a configuração não referenciar projetos externos (o que descaracteriza o multi-project), há apenas uma referência a um arquivo local, portanto apenas um pipeline é criado. A alternativa erra tanto no tipo de pipeline quanto na quantidade.
Alternativa E — ❌ Incorreta
A alternativa está incorreta porque afirma que são disparados dois pipelines, um de cada tipo. A configuração apresentada contém apenas uma referência a um arquivo de configuração local, o que gera apenas um pipeline do tipo parent-child. Não há referência a projetos externos, portanto não há pipeline multi-project.
Gabarito: letra A
Considere que os arquivos referenciados são válidos e acessíveis. Com essa configuração, ao ser executado, o job microservico_A irá disparar, ao todo: