Componentes de pipeline

Cada repositório do Airframe monta o seu pipeline com os componentes da plataforma, peças compartilhadas guardadas no repositório control-plane, em vez de jobs próprios. Esta página lista cada componente que um repositório pode incluir, os jobs que ele acrescenta e do que precisa para rodar, e depois os jobs que a plataforma injeta nos pipelines, diga o arquivo o que disser, para que você possa ler o pipeline de qualquer repositório e saber de onde vem cada job.

Como ler as tabelas

Um componente é incluído como gitlab.com/projectairframe/control-plane/<name>@<commit>, num commit completo, que o comando airframe pin escreve; o pacote de políticas alerta sobre um branch, uma tag ou um commit abreviado. Ele recebe entradas, nunca variáveis. O arquivo de pipeline de um produto é renderizado pelo template do golden path, e o pacote de políticas recusa um arquivo de produto que inclua algo além de oito destes componentes ou que declare um job que faz deploy (aplicado). A página de regras de políticas lista essas regras.

Os jobs rodam num de dois runners: o runner não confiável, que não tem nenhuma credencial e roda o que um merge request trouxer, e o runner confiável, que roda só numa main protegida e obtém identidades pela federação de identidade de carga de trabalho. O glossário explica os dois.

As tabelas descrevem a versão da plataforma 2026.10.01-1, cujo commit do control-plane é c53c0bc. Uma linha marcada como projetado é um componente que os contratos nomeiam e que não está construído.

Os componentes

`tf-apply`

Jobs: plan:<name>, ou plan-after:<name> para uma raiz que planeja depois do apply de outras raízes; policy:<name>; apply:<name>; run-job:<name> quando a raiz roda um job depois do seu apply; e drift:<name> no pipeline agendado.
Entradas que um repositório define: Uma inclusão por raiz de Terraform: name, root, root_kind, identity, state_bucket, state_prefix e environment. O arquivo de um produto também define lifecycle, extra_changes, run_job, run_job_after e, para a produção, after. As raízes da plataforma podem definir reads_catalog, plan_after, plan_late, secret_env, smoke, drift_only e forget_projects.
Do que precisa: O runner confiável, uma main protegida e a identidade da raiz no ambiente da raiz. Os jobs de plan, de política e de apply rodam só na main, quando os arquivos da raiz mudaram.
Fonte: control-plane templates/tf-apply/template.yml, docs/pipeline.md; golden-path template/.gitlab-ci.yml.jinja

`drift-report`

Jobs: drift:report, no pipeline agendado, depois dos jobs de desvio.
Entradas que um repositório define: Nenhuma na prática: cada entrada tem um valor padrão.
Do que precisa: O runner confiável; a identidade de auditoria, no ambiente platform/audit; o token do GitLab da conta de auditoria, lido do Secret Manager no job; e um agendamento na main que um mantenedor cria.
Fonte: control-plane templates/drift-report/template.yml, docs/pipeline.md

`image-build`

Jobs: build:request, na main.
Entradas que um repositório define: wait_minutes e gate_url. As entradas identity, environment e as dos registros foram aposentadas e são ignoradas.
Do que precisa: O runner não confiável e o token do job para o controle de aprovação, sem identidade de nuvem. O construtor confiável construiu o commit na aprovação, ou o constrói agora a pedido do job.
Fonte: control-plane templates/image-build/template.yml

`promote-artifact`

Jobs: deploy:promote, na main, depois de build:request.
Entradas que um repositório define: wait_minutes e gate_url. As suas entradas antigas são aceitas e ignoradas.
Do que precisa: Nenhuma credencial: ele pede ao controle de aprovação, e o executor copia a imagem por digest para o registry de produção como o promotor de artefatos. O apply de produção espera por ele.
Fonte: control-plane templates/promote-artifact/template.yml, docs/pipeline.md

`catalog-publish`

Jobs: validate:fragment nos merge requests; release:catalog na main.
Entradas que um repositório define: kind, path, identity e environment; um repositório da plataforma também define name.
Do que precisa: validate:fragment: o runner não confiável, nenhuma credencial. release:catalog: o runner confiável e a identidade própria do repositório, para um produto a sua identidade de apply de produção no ambiente prod.
Fonte: control-plane templates/catalog-publish/template.yml, docs/pipeline.md

`reconcile`

Jobs: <name>:reconcile, por convenção edge:reconcile e grafana:reconcile, na main depois dos jobs de apply.
Entradas que um repositório define: name, repository (landing-zone ou operations), after e changes.
Do que precisa: O token do job para o controle de aprovação, que inicia o pipeline da main do repositório da plataforma com o token de disparo da própria plataforma. Sem identidade de nuvem.
Fonte: control-plane templates/reconcile/template.yml

`progress`

Jobs: progress:track, no pipeline da main do catálogo depois de uma mesclagem que mudou um arquivo de produto.
Entradas que um repositório define: Nenhuma na prática; só o catálogo o inclui.
Do que precisa: O runner não confiável e o token do job para o controle de aprovação, que escreve a nota no merge request mesclado. Ele acompanha a mesclagem por até três horas.
Fonte: control-plane templates/progress/template.yml; catalog .gitlab-ci.yml

`validate`

Jobs: validate:terraform, validate:tofu, validate:tflint, validate:policy e validate:catalog.
Entradas que um repositório define: Um repositório da plataforma define terraform_roots, root_kind e, no catálogo, catalog_lint. Um produto não define nada: a política de produtos o injeta.
Do que precisa: O runner não confiável, nenhuma credencial e só imagens públicas.
Fonte: control-plane templates/validate/template.yml, docs/pipeline.md

`build-test`

Jobs: build:test-node, build:test-python com build:web-python, ou build:test-java, conforme os arquivos da pilha; depois build:quality.
Entradas que um repositório define: Nenhuma: ele é injetado em cada pipeline de produto e nunca incluído.
Do que precisa: O runner não confiável e nenhuma credencial. Os limites de cobertura e de achados vêm do campo quality do produto no catálogo.
Fonte: control-plane templates/build-test/template.yml, docs/pipeline.md

O arquivo renderizado de um produto inclui image-build, promote-artifact, quatro inclusões de tf-apply para prod, sandbox, np e grafana, drift-report, catalog-publish, e duas vezes reconcile. Um repositório da plataforma com raízes de Terraform inclui validate e um tf-apply para cada raiz que aplica; a maioria também inclui drift-report e catalog-publish, e os que constroem imagens, image-build e promote-artifact.

Os jobs injetados

As políticas do GitLab guardadas no repositório security-policies acrescentam estes jobs aos pipelines. O arquivo próprio de um repositório não pode remover nem substituir um job injetado (aplicado pelas políticas de execução de pipeline do GitLab), então um time não define nada aqui.

`gate:integrity`

Onde roda: Cada pipeline de cada repositório do grupo menos o security-policies, no estágio anterior a todos os outros.
O que faz: Pede ao controle de aprovação o seu veredito sobre o commit do pipeline e falha quando o veredito é negativo, quando o endereço está vazio ou quando o controle não responde. O endereço é o do próprio job, e a política não permite sobrescrever variáveis, então nenhuma variável de projeto, de grupo ou de pipeline chega ao job. O controle também faz falhar um pipeline fixado numa versão da plataforma revogada.
Do que precisa: Um token cujo destinatário é o controle de aprovação. Ele não baixa nenhum código.
Fonte: security-policies templates/airframe.yml, .gitlab/security-policies/policy.yml

`validate:injected`

Onde roda: Cada pipeline do grupo menos os do security-policies, nos merge requests e na main.
O que faz: Marca que o estágio de validação está presente; os componentes rodam as verificações.
Do que precisa: Nada.
Fonte: security-policies templates/airframe.yml

As verificações de produto

Onde roda: Cada pipeline de um repositório dos grupos de jornada, onde ficam os produtos.
O que faz: O componente validate sobre as raízes infra/prod, infra/np, infra/sandbox, infra/grafana e infra/eph, com o pacote de políticas, e o componente build-test.
Do que precisa: O runner não confiável e nenhuma credencial.
Fonte: security-policies templates/product.yml, .gitlab/security-policies/policy.yml

Detecção de segredos, análise de dependências e SAST

Onde roda: Cada pipeline de merge request do grupo, e uma análise diária de cada branch padrão.
O que faz: Os analisadores do próprio GitLab. Os seus achados aparecem no merge request e ainda não bloqueiam nada.
Do que precisa: Nada do repositório: a política de execução de análises define os jobs.
Fonte: security-policies .gitlab/security-policies/policy.yml

Nomeados nos contratos, hoje não são componentes

`deploy-cloud-run`projetado

Jobs: deploy:sandbox, deploy:prod, deploy:canary, deploy:shift-<pct> e deploy:rollback
Hoje: Não está construído. Os jobs de apply do tf-apply fazem o deploy de cada imagem por digest, e a ordem canário da criticidade 1 é projetada.
Fonte: landing-zone docs/contracts.md 5.1, docs/adaptations.md

`security-scan`projetado

Jobs: verify:dependencies, verify:container e verify:licences
Hoje: Não está construído como componente. Os analisadores do GitLab chegam pela política de execução de análises, e o construtor confiável analisa cada imagem que constrói.
Fonte: landing-zone docs/contracts.md 5.1; control-plane docs/pipeline.md

`pact-publish`, `pact-can-i-deploy`projetado

Jobs: verify:pact-publish e deploy:can-i-deploy
Hoje: Não está construído: nenhum broker de contratos está rodando.
Fonte: landing-zone docs/contracts.md 5.1

`release`projetado

Jobs: release:tag
Hoje: Não está construído.
Fonte: landing-zone docs/contracts.md 5.1

`ops`projetado

Jobs: ops:restart, ops:scale, ops:rollback e outros seis jobs operacionais
Hoje: Não está construído.
Fonte: landing-zone docs/contracts.md 5.1

`renovate`projetado

Jobs: ops:renovate, agendado
Hoje: Não está construído.
Fonte: landing-zone docs/contracts.md 5.1

`tf-plan`, `cost-estimate`, `preview-env`, `destroy-on-close`

Jobs: Os planos na aprovação, o seu preço, uma prévia e a sua destruição
Hoje: Construídos como execuções do executor, que o controle de aprovação inicia. Um repositório não inclui nenhum deles.
Fonte: landing-zone docs/contracts.md 5.1, 5.3; control-plane executor/

Os contratos dão nomes antigos a alguns jobs, como deploy:apply-<root>. As tabelas usam os nomes que os componentes definem.

Onde fica

No repositório control-plane:

No repositório security-policies:

Componentes de pipeline

Como ler as tabelas

Os componentes

tf-apply

drift-report

image-build

promote-artifact

catalog-publish

reconcile

progress

validate

build-test