Componentes de pipeline

Cada repositorio de Airframe arma su pipeline con los componentes de la plataforma, piezas compartidas que se guardan en el repositorio control-plane, en lugar de con jobs propios. Esta página enumera cada componente que un repositorio puede incluir, los jobs que agrega y lo que necesita para ejecutarse, y luego los jobs que la plataforma inyecta en los pipelines diga lo que diga su archivo, para que pueda leer el pipeline de cualquier repositorio y saber de dónde viene cada job.

Cómo leer las tablas

Un componente se incluye como gitlab.com/projectairframe/control-plane/<name>@<commit>, en un commit completo, que escribe el comando airframe pin; el paquete de políticas advierte sobre una rama, una etiqueta o un commit abreviado. Recibe entradas, nunca variables. El archivo de pipeline de un producto lo genera el template del golden path, y el paquete de políticas rechaza un archivo de producto que incluya algo distinto de ocho de estos componentes o que declare un job que despliega (aplicado). La página de reglas de políticas enumera esas reglas.

Los jobs se ejecutan en uno de dos runners: el runner sin confianza, que no tiene ninguna credencial y ejecuta lo que traiga un merge request, y el runner de confianza, que se ejecuta solo en un main protegido y obtiene identidades mediante la federación de identidades de carga de trabajo. El glosario explica los dos.

Las tablas describen la versión de la plataforma 2026.10.01-1, cuyo commit de control-plane es c53c0bc. Una fila marcada como diseñado es un componente que los contratos nombran y que no está construido.

Los componentes

`tf-apply`

Jobs: plan:<name>, o plan-after:<name> para una raíz que planifica después del apply de otras raíces; policy:<name>; apply:<name>; run-job:<name> cuando la raíz ejecuta un job después de su apply; y drift:<name> en el pipeline programado.
Entradas que fija un repositorio: Una inclusión por raíz de Terraform: name, root, root_kind, identity, state_bucket, state_prefix y environment. El archivo de un producto también fija lifecycle, extra_changes, run_job, run_job_after y, para producción, after. Las raíces de la plataforma pueden fijar reads_catalog, plan_after, plan_late, secret_env, smoke, drift_only y forget_projects.
Qué necesita: El runner de confianza, un main protegido y la identidad de la raíz en el entorno de la raíz. Los jobs de plan, de política y de apply se ejecutan solo en main, cuando cambiaron los archivos de la raíz.
Fuente: control-plane templates/tf-apply/template.yml, docs/pipeline.md; golden-path template/.gitlab-ci.yml.jinja

`drift-report`

Jobs: drift:report, en el pipeline programado, después de los jobs de deriva.
Entradas que fija un repositorio: Ninguna en la práctica: cada entrada tiene un valor por defecto.
Qué necesita: El runner de confianza; la identidad de auditoría, en el entorno platform/audit; el token de GitLab de la cuenta de auditoría, leído de Secret Manager en el job; y una programación en main que crea un mantenedor.
Fuente: control-plane templates/drift-report/template.yml, docs/pipeline.md

`image-build`

Jobs: build:request, en main.
Entradas que fija un repositorio: wait_minutes y gate_url. Las entradas identity, environment y las de los registros están retiradas y se ignoran.
Qué necesita: El runner sin confianza y el token del job para la compuerta de aprobación, sin identidad de nube. El constructor de confianza construyó el commit en la aprobación, o lo construye ahora a pedido del job.
Fuente: control-plane templates/image-build/template.yml

`promote-artifact`

Jobs: deploy:promote, en main, después de build:request.
Entradas que fija un repositorio: wait_minutes y gate_url. Sus entradas anteriores se aceptan y se ignoran.
Qué necesita: Ninguna credencial: le pide a la compuerta de aprobación, y el ejecutor copia la imagen por digest al registro de producción como el promotor de artefactos. El apply de producción la espera.
Fuente: control-plane templates/promote-artifact/template.yml, docs/pipeline.md

`catalog-publish`

Jobs: validate:fragment en los merge requests; release:catalog en main.
Entradas que fija un repositorio: kind, path, identity y environment; un repositorio de la plataforma también fija name.
Qué necesita: validate:fragment: el runner sin confianza, ninguna credencial. release:catalog: el runner de confianza y la identidad propia del repositorio, para un producto su identidad de apply de producción en el entorno prod.
Fuente: control-plane templates/catalog-publish/template.yml, docs/pipeline.md

`reconcile`

Jobs: <name>:reconcile, por convención edge:reconcile y grafana:reconcile, en main después de los jobs de apply.
Entradas que fija un repositorio: name, repository (landing-zone u operations), after y changes.
Qué necesita: El token del job para la compuerta de aprobación, que inicia el pipeline de main del repositorio de la plataforma con el token de disparo propio de la plataforma. Sin identidad de nube.
Fuente: control-plane templates/reconcile/template.yml

`progress`

Jobs: progress:track, en el pipeline de main del catálogo después de una fusión que cambió un archivo de producto.
Entradas que fija un repositorio: Ninguna en la práctica; solo el catálogo lo incluye.
Qué necesita: El runner sin confianza y el token del job para la compuerta de aprobación, que escribe la nota en el merge request fusionado. Sigue la fusión durante hasta tres horas.
Fuente: control-plane templates/progress/template.yml; catalog .gitlab-ci.yml

`validate`

Jobs: validate:terraform, validate:tofu, validate:tflint, validate:policy y validate:catalog.
Entradas que fija un repositorio: Un repositorio de la plataforma fija terraform_roots, root_kind y, en el catálogo, catalog_lint. Un producto no fija nada: lo inyecta la política de productos.
Qué necesita: El runner sin confianza, ninguna credencial y solo imágenes públicas.
Fuente: control-plane templates/validate/template.yml, docs/pipeline.md

`build-test`

Jobs: build:test-node, build:test-python con build:web-python, o build:test-java, según los archivos de la pila; luego build:quality.
Entradas que fija un repositorio: Ninguna: se inyecta en cada pipeline de producto y nunca se incluye.
Qué necesita: El runner sin confianza y ninguna credencial. Los umbrales de cobertura y de hallazgos vienen del campo quality del producto en el catálogo.
Fuente: control-plane templates/build-test/template.yml, docs/pipeline.md

El archivo generado de un producto incluye image-build, promote-artifact, cuatro inclusiones de tf-apply para prod, sandbox, np y grafana, drift-report, catalog-publish, y dos veces reconcile. Un repositorio de la plataforma con raíces de Terraform incluye validate y un tf-apply por cada raíz que aplica; la mayoría también incluye drift-report y catalog-publish, y los que construyen imágenes, image-build y promote-artifact.

Los jobs inyectados

Las políticas de GitLab que se guardan en el repositorio security-policies agregan estos jobs a los pipelines. El archivo propio de un repositorio no puede quitar ni reemplazar un job inyectado (aplicado por las políticas de ejecución de pipelines de GitLab), así que un equipo no fija nada aquí.

`gate:integrity`

Dónde se ejecuta: Cada pipeline de cada repositorio del grupo salvo security-policies, en la etapa anterior a todas las demás.
Qué hace: Pide a la compuerta de aprobación su veredicto sobre el commit del pipeline y falla cuando el veredicto es negativo, cuando la dirección está vacía o cuando la compuerta no responde. La dirección es la del propio trabajo, y la política no permite anular variables, así que ninguna variable de proyecto, de grupo o de pipeline llega al trabajo. La compuerta también hace fallar un pipeline fijado a una versión de la plataforma revocada.
Qué necesita: Un token cuyo destinatario es la compuerta. No obtiene ningún código.
Fuente: security-policies templates/airframe.yml, .gitlab/security-policies/policy.yml

`validate:injected`

Dónde se ejecuta: Cada pipeline del grupo salvo los de security-policies, en los merge requests y en main.
Qué hace: Marca que la etapa de validación está presente; los componentes ejecutan las comprobaciones.
Qué necesita: Nada.
Fuente: security-policies templates/airframe.yml

Las comprobaciones de producto

Dónde se ejecuta: Cada pipeline de un repositorio de los grupos de recorrido, donde están los productos.
Qué hace: El componente validate sobre las raíces infra/prod, infra/np, infra/sandbox, infra/grafana e infra/eph, con el paquete de políticas, y el componente build-test.
Qué necesita: El runner sin confianza y ninguna credencial.
Fuente: security-policies templates/product.yml, .gitlab/security-policies/policy.yml

Detección de secretos, análisis de dependencias y SAST

Dónde se ejecuta: Cada pipeline de merge request del grupo, y un análisis diario de cada rama por defecto.
Qué hace: Los analizadores propios de GitLab. Sus hallazgos aparecen en el merge request y todavía no bloquean nada.
Qué necesita: Nada del repositorio: la política de ejecución de análisis define los jobs.
Fuente: security-policies .gitlab/security-policies/policy.yml

Nombrados en los contratos, hoy no son componentes

`deploy-cloud-run`diseñado

Jobs: deploy:sandbox, deploy:prod, deploy:canary, deploy:shift-<pct> y deploy:rollback
Hoy: No está construido. Los jobs de apply de tf-apply despliegan cada imagen por digest, y el orden canario de la criticidad 1 está diseñado.
Fuente: landing-zone docs/contracts.md 5.1, docs/adaptations.md

`security-scan`diseñado

Jobs: verify:dependencies, verify:container y verify:licences
Hoy: No está construido como componente. Los analizadores de GitLab llegan por la política de ejecución de análisis, y el constructor de confianza analiza cada imagen que construye.
Fuente: landing-zone docs/contracts.md 5.1; control-plane docs/pipeline.md

`pact-publish`, `pact-can-i-deploy`diseñado

Jobs: verify:pact-publish y deploy:can-i-deploy
Hoy: No está construido: no funciona ningún broker de contratos.
Fuente: landing-zone docs/contracts.md 5.1

`release`diseñado

Jobs: release:tag
Hoy: No está construido.
Fuente: landing-zone docs/contracts.md 5.1

`ops`diseñado

Jobs: ops:restart, ops:scale, ops:rollback y otros seis jobs operativos
Hoy: No está construido.
Fuente: landing-zone docs/contracts.md 5.1

`renovate`diseñado

Jobs: ops:renovate, programado
Hoy: No está construido.
Fuente: landing-zone docs/contracts.md 5.1

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

Jobs: Los planes en la aprobación, su precio, una vista previa y su destrucción
Hoy: Construidos como ejecuciones del ejecutor, que inicia la compuerta de aprobación. Un repositorio no incluye ninguno.
Fuente: landing-zone docs/contracts.md 5.1, 5.3; control-plane executor/

Los contratos dan nombres anteriores a algunos jobs, como deploy:apply-<root>. Las tablas usan los nombres que definen los componentes.

Dónde está

En el repositorio control-plane:

En el repositorio security-policies:

Componentes de pipeline

Cómo leer las tablas

Los componentes

tf-apply

drift-report

image-build

promote-artifact

catalog-publish

reconcile

progress

validate

build-test