promoción a main: el build de imagen es ahora un check del PR, y su verde significa algo - #681
Merged
Conversation
…es promociones despues El job que construye las tres imagenes de servicio estaba gateado a `main` y a tags. Eso ponia la pregunta "esto todavia construye?" despues de todas las puertas que podrian haberla parado: un Dockerfile roto de agent-runtime cruzo los PR #669, #670 y #673 con 46, 78 y 47 checks en verde cada uno, y lo encontro un humano leyendo el registry. El build pasa a correr en cada PR; el push sigue gateado a main y tags, que es exactamente la conducta de publicacion que el job ya tenia. En un pull request `github.ref` es refs/pull/N/merge, asi que no se hace login contra GHCR ni sale nada hacia el registry: el PR demuestra que la imagen compila, y nada mas. Un matrix reporta un check por rama y cada contexto arrastra sus parametros --- "(core-api, ., ./src/apps/core-api/Dockerfile)" ---, que cambian cuando cambia una ruta. Por eso las tres se colapsan en un job sin matrix, `Services build (GHCR)`, con nombre estable: ese es el contexto que la proteccion de rama puede exigir. Trata `skipped` como paso porque significa que fallo una suite previa, y esa ya tiene su propio check en rojo; duplicarlo solo aniade ruido. Con el build ahora en la ruta caliente de cada PR, se aniade cache de GitHub Actions con scope por servicio, para que las tres ramas no se desalojen entre si. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: aarroyo <beyondnet.peru@gmail.com>
ci(imágenes): el build de imagen pasa a ser un check del PR
Ayer di por bueno que `skipped` pasara. El razonamiento era que un skip significa que fallo una suite previa, y esa ya lleva su propio check en rojo. La premisa era cierta y la conclusion era falsa: ese rojo no bloquea. `docker-services` depende de siete jobs de test, y dos de ellos --- `test-sdk-client` y `test-infra-providers` --- no son contextos requeridos ni en main ni en develop. Asi que un Dockerfile roto llegando junto a un solo flake en cualquiera de esas dos suites saltaba el build, reportaba este check en VERDE sin haber construido nada, y dejaba los ocho contextos requeridos satisfechos. Es exactamente el fallo que el job existe para impedir, ahora con chapa de check requerido. Un check requerido tiene que afirmar que el build CORRIO, no solo que no fallo. Dos rojos en vez de uno no es duplicar el reporte: es este check negandose a responder por algo que nunca vio. Segundo arreglo, del mismo cambio de ayer: `cache-to` escribia en cada PR. Tres imagenes en mode=max son cerca de un giga por run, y la cache de Actions es un unico pozo de 10 GB que ya guarda ~1.7 GB de los que dependen los tests. Cada PR escribiendo su copia habria desalojado por LRU las caches de npm, y eso se habria visto como las suites de test volviendose lentas sin motivo. Ahora todos leen y solo publican los refs que publican. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: aarroyo <beyondnet.peru@gmail.com>
fix(ci): que el verde de «Services build (GHCR)» signifique que algo se construyó
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
📊 Bilingual Coverage ImpactPR Changes
Repository Coverage
✅ Good: All EN changes have ES counterparts. Generated by GitHub Actions |
beyondnetPeru
added a commit
that referenced
this pull request
Sep 2, 2026
chore(release): realinear develop con main tras la promoción #681
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promoción de #679 + #680.
Qué llega a main
El build de las tres imágenes de servicio pasa a correr en cada PR. Estaba gateado a
mainy tags, así que la pregunta «¿esto todavía construye?» se hacía después de todas las puertas que podrían haber parado el cambio. UnDockerfileroto deagent-runtimecruzó los PR #669, #670 y #673 con 46, 78 y 47 checks en verde, y lo encontró un humano leyendo el registry.El push sigue gateado a
mainy tags: publicación sin cambio.Las tres ramas del matrix se colapsan en un contexto estable,
Services build (GHCR), que es lo que la protección de rama puede exigir — los contextos de matrix arrastran sus parámetros y cambian cuando cambia una ruta.El gate solo pasa en
successLa primera versión dejaba pasar
skipped. La premisa —«un skip significa que falló una suite previa, y esa ya lleva su rojo»— era cierta; la conclusión era falsa: ese rojo no bloquea.test-sdk-clientytest-infra-providersno son contextos requeridos, así que un Dockerfile roto más un flake en cualquiera de las dos habría dado verde sin construir nada. Corregido en #680.Lo probado en vivo, no argumentado
env.PUBLISHenif:de stepLogin to GHCR→ skipped en el run del PRenv.PUBLISHenwith:push: falsecache-tocondicionaldocker buildx buildsalió con--cache-fromy sin--cache-toServices build (GHCR), verbatim, sin prefijo ni sufijoLo que este PR sí prueba y no probaba ninguno de los dos anteriores
En un
pull_request,github.refesrefs/pull/N/merge, así quePUBLISHesfalsey la ruta de publicación nunca se ejercita. Al mergear esto amain,PUBLISHpasa atruepor primera vez. Verifico contra GHCR —digest y fecha de las tres imágenes— en vez de contra el color del check.Después del merge
Marcar
Services build (GHCR)como contexto requerido enmainy endevelop. Las dos protecciones son idénticas hoy; dejarlas divergir es cómo se termina saltando el check.🤖 Generated with Claude Code