CRUX Portbot nació alrededor de un pipeline Live para amd64 capaz de descubrir actualizaciones de ports, preparar candidatos, construirlos, firmarlos y generar propuestas de publicación.
El siguiente problema es bastante más interesante: llevar ese mismo modelo a varias arquitecturas sin convertirlo en varios pipelines independientes y sin perder las garantías que ya existen entre sus distintas etapas.
El punto de partida
Portbot no está diseñado como una secuencia de scripts que modifican un mismo árbol de trabajo.
Las distintas etapas están separadas por fronteras explícitas. Un candidato preparado se serializa antes de llegar al build; el resultado del build vuelve a cruzar otra frontera; la firma está aislada del proceso que construye el port; y la publicación dispone de sus propias credenciales y validaciones.
De forma simplificada:
discovery
↓
selected candidates
↓
prepare
↓
candidate handoff
↓
build
↓
build-output handoff
↓
signature preparation
↓
isolated signer
↓
finalizer
↓
publication handoff
↓
publisherLas flechas son importantes: representan estado serializado y validado, no un worktree mutable que una etapa deja preparado para la siguiente.
El problema multi-arquitectura
Añadir más arquitecturas podría parecer simplemente una cuestión de ejecutar el build varias veces.
No lo es.
Cada arquitectura necesita su propio entorno de ejecución, builder y colecciones de ports, mientras que el comportamiento general del pipeline debería seguir siendo el mismo.
La implementación actual está evolucionando hacia una matriz común:
Portbot Live
│
reusable worker
│
┌────────────────┼────────────────┬────────────────┐
│ │ │ │
x86_64 armhf arm64 riscv64
│ │ │ │
CRUX CRUX-ARM CRUX-ARM CRUX-RISCVEl objetivo no es mantener cuatro Portbots.
Es mantener un mismo modelo de ejecución capaz de introducir las diferencias necesarias en los límites adecuados.
Un worker, varios entornos
Cada entrada de la matriz selecciona el runner, la imagen de construcción y las colecciones correspondientes a su arquitectura.
El resto del workflow se delega en el mismo worker reutilizable.
Esto permite que la arquitectura física cambie sin duplicar la lógica que define cómo se descubre, prepara, construye, valida, firma o publica un candidato.
También obliga a identificar qué partes del sistema son realmente comunes y cuáles pertenecen a una arquitectura concreta.
Esa frontera es uno de los puntos que estamos explorando ahora.
Cuando un port necesita divergir
No todos los ports específicos de una arquitectura evolucionan de forma independiente.
Parte del trabajo consiste en mantener overlays que introducen las diferencias necesarias sobre colecciones existentes sin convertirlas en copias completamente separadas.
Portbot puede comparar el estado de esos overlays con el repositorio que actúa como referencia.
reference port
│
│ version / release
▼
architecture overlay
│
├── synchronized ──────── no candidate
│
└── different ─────────── overlay candidateCuando detecta una diferencia relevante, ésta puede normalizarse como un candidato de tipo overlay y entrar en el proceso de preparación y validación.
Esto convierte el problema multi-arquitectura en algo más que decidir dónde compilar.
También hay que decidir dónde viven las diferencias entre arquitecturas y cómo se propagan sin perder su contexto.
Preservar las fronteras
La transición a multi-arquitectura tiene una restricción importante: no debería debilitar el modelo de confianza existente.
Algunas de sus propiedades son deliberadamente estrictas:
- los candidatos deben poder reconstruirse desde estado serializado;
- prepare y build no reciben la clave privada de firma;
- el signer no dispone de red ni de checkout del repositorio;
- el token de publicación sólo existe en el publisher;
- las etapas importantes validan los datos antes de importarlos;
- un fallo de un candidato no equivale automáticamente a un fallo del pipeline.
Por tanto, el objetivo no es:
amd64 pipeline × 4sino algo más cercano a:
existing pipeline invariants
│
▼
architecture-aware
execution
│
┌───────────┼───────────┐
▼ ▼ ▼
ARM RISC-V x86_64La arquitectura puede cambiar. Las garantías no deberían hacerlo accidentalmente.
Dónde estamos ahora
La ejecución Live ya dispone de una matriz para x86_64, armhf, arm64 y riscv64 utilizando un worker común.
El soporte de overlays también está entrando en ese mismo modelo: la detección de diferencias, su representación como candidatos y su preparación forman parte del trabajo actual.
Eso significa que la transición todavía no está cerrada.
Precisamente por eso pertenece al Lab.
No estamos documentando una arquitectura terminada, sino observando qué ocurre cuando un pipeline diseñado alrededor de una única arquitectura empieza a tener que representar varias.
Lo que estamos intentando demostrar
La pregunta no es si CRUX puede construir ports en ARM o RISC-V. Eso ya sabemos hacerlo.
La pregunta es si podemos hacer que un único sistema de automatización entienda esas arquitecturas, preserve sus diferencias y mantenga las mismas fronteras de confianza durante todo el proceso.
Si funciona, multi-arquitectura dejará de ser una colección de excepciones alrededor del CI.
Pasará a ser una propiedad del propio pipeline.
