fix(ci): que el verde de «Services build (GHCR)» signifique que algo se construyó

[beyondnetPeru]

Antes de marcar Services build (GHCR) como check requerido, audité el cambio de #679 con cuatro lentes independientes y un pase de refutación. Encontró un agujero real, y era mío.

El defecto

Escribí que el gate tratara skipped como paso, razonando que un skip significa que falló una suite previa y que esa ya lleva su propio check en rojo.

La premisa era cierta. La conclusión era falsa: ese rojo no bloquea.

docker-services depende de siete jobs de test. Dos de ellos —test-sdk-client y test-infra-providers— no son contextos requeridos ni en main ni en develop. La cadena completa:

Dockerfile roto  +  un flake en test-infra-providers
        ↓
docker-services → skipped   (un job de sus needs falló)
        ↓
Services build (GHCR) → VERDE   (la rama skipped salía con exit 0)
        ↓
los 8 contextos requeridos, verdes  →  mergeable

Es el fallo que el job existe para impedir, ahora con chapa de check requerido. Y main no tiene required_pull_request_reviews, así que esos ocho contextos son la puerta entera: no hay revisor obligatorio que note el rojo no bloqueante.

El arreglo

Solo success pasa. Cualquier otra cosa —skipped, cancelled, failure— sale en rojo con un mensaje que dice por qué. Un check requerido tiene que afirmar que el build corrió, no solo que no falló. Dos rojos en vez de uno no es duplicar el reporte: es este check negándose a responder por algo que nunca vio.

Segundo arreglo, del mismo cambio

cache-to escribía en cada PR. Tres imágenes en mode=max son ~1 GB por run, y la cache de Actions es un único pozo de 10 GB que ya guarda ~1.7 GB de los que dependen los tests. Cada PR escribiendo su copia habría desalojado por LRU las caches de npm — y eso no se habría visto como un problema de cache, sino como las suites de test volviéndose lentas sin motivo. Ahora todos leen; solo escriben los refs que publican.

Lo que la auditoría confirmó que sí está bien

• env.PUBLISH resuelve correctamente en steps[*].if y en steps[*].with — probado en vivo en ci(imágenes): el build de imagen pasa a ser un check del PR #679: Login to GHCR salió skipped y la acción recibió push: false.
• Ningún deploy puede dispararse desde un PR; ningún secret ni credencial de GHCR se consume en contexto pull_request, tampoco desde un fork.
• Un PR malicioso no puede envenenar una cache que consuma main (el aislamiento de caches de GHA lo impide).
• El contexto se llama exactamente Services build (GHCR), sin prefijo de workflow ni sufijo de matrix.

Doce hallazgos más fueron refutados en el pase adversarial y no están aquí.

Queda dicho, no hecho

• docker/build-push-action@v5 y setup-buildx-action@v3 apuntan al runtime Node 20, en migración forzada por GitHub. Rompería en rojo, no en silencio.
• Marcar el check requerido sube el camino crítico del PR de 4m31s a 7m53s, porque el build va en serie detrás de las siete suites. Se puede recortar, pero es una decisión aparte.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[github-actions]

📊 Bilingual Coverage Impact

PR Changes

• Paired EN/ES files modified: 1
• New EN files needing ES translation: 0

Repository Coverage

Metric	Value
Total EN files	527
Total ES files	497
Paired files	0
Coverage	0%

✅ Good: All EN changes have ES counterparts.

---

Generated by GitHub Actions