Versiones de la plataforma

Cada repositorio de Airframe ejecuta en su pipeline las herramientas propias de la plataforma: los componentes de pipeline, el paquete de políticas y las políticas de seguridad inyectadas; y cada producto parte de la plantilla de producto de la plataforma. Una versión de la plataforma fija exactamente qué versión de cada una de esas partes va junta, con un nombre fechado como 2026.09.30-2. Los repositorios pasan de una versión a la siguiente a propósito, y una versión con una falla se puede revocar, lo que detiene todo pipeline nuevo que todavía la use.

Por qué existen las versiones

Las herramientas de la plataforma cambian seguido, y un pipeline que tomara en silencio la versión más nueva de cada parte se rompería de formas que nadie podría rastrear. Además, las partes dependen unas de otras: la plantilla incluye los componentes de pipeline, y las skills se prueban contra el paquete de políticas. Un cambio en una tiene que verificarse contra las demás antes de que alguien lo ejecute.

Una versión resuelve los dos problemas. Nombra una combinación probada, y cada repositorio dice qué combinación ejecuta.

Qué es una versión

Una versión es un archivo pequeño en el repositorio control-plane, releases/<id>.yaml, llamado manifiesto. Nombra el commit exacto de cada una de cinco partes:

control-plane: los componentes de pipeline, el paquete de políticas y las imágenes de la plataforma;
golden-path: la plantilla de producto;
los módulos: los módulos de Terraform que usa la plantilla;
security-policies: los trabajos que se inyectan en cada pipeline de producto;
platform-skills: las skills que carga un agente de código.

Un segundo archivo, releases/permitted.yaml, enumera cada versión y si puede ejecutarse: permitted, o revoked con un motivo y la versión a la que hay que pasar. Un manifiesto nunca se borra, así que el registro de lo que se ejecutó se conserva.

Cómo se hace una versión

Cortar una versión es una secuencia corta de merge requests:

Cada parte se fija a las demás en los commits nuevos, con un merge request por repositorio. El comando airframe pin <commit> reescribe los includes del archivo de pipeline.
Un merge request en control-plane agrega el manifiesto y su línea permitted. Dos trabajos deben pasar antes de poder integrarlo: release:check trae cada commit nombrado y falla si una parte fija un commit distinto del que nombra la versión, y la familia de trabajos release:verify ejecuta las propias verificaciones de cada parte en esos commits, como las pruebas del paquete de políticas, las tres pilas de la plantilla, las pruebas de los módulos y las pruebas de las skills.

Solo una versión que pasó las dos cosas llega a estar permitida.

Cómo usa un repositorio una versión

Un repositorio pasa a una versión con airframe pin --release <id>, que reescribe los includes de su archivo de pipeline a los commits de la versión, y un merge request sin nada más. Volver atrás es el mismo comando con la versión anterior. Como solo cambia el archivo de pipeline, es fácil de revisar y fácil de deshacer.

Revocar una versión

Cuando una revisión encuentra una falla en una versión, la corrección es un merge request que cambia su línea en releases/permitted.yaml a revoked, con un motivo y un upgrade_to.

Desde ese momento, dos cosas la rechazan:

la compuerta de aprobación, en cada pipeline nuevo: su trabajo de integridad lee el archivo de pipeline en el commit, lo compara con la lista de permitidas en la rama main de control-plane, y hace fallar un pipeline fijado a una versión revocada, nombrando la versión a la que hay que pasar;
el ejecutor, en cada ejecución de merge request y de versión, antes de tener cualquier credencial.

Esto ya ocurrió. Las versiones 2026.09.28-1, 2026.09.28-2 y 2026.09.29-1 se revocaron después de que las revisiones del 2026-09-29 encontraran fallas en sus trabajos de pipeline, y la lista de permitidas nombra 2026.09.30-1 como la versión a la que hay que pasar.

Qué hace un equipo cuando se revoca su versión

El pipeline que falla dice qué hacer: ejecutar airframe pin --release con la versión que nombra, y abrir un merge request solo con ese cambio. Cuando se integra, los pipelines del repositorio vuelven a ejecutarse. Un commit que ninguna versión nombra, o una referencia que se mueve, como una rama, hoy es una advertencia y está previsto que pase a ser un rechazo en la próxima versión.

Dónde está

En el repositorio control-plane: