ci(release): quitar el filtro de rutas del pull_request, precondición de GT-710 - #693
Merged
Merged
Conversation
…econdicion de GT-710 `build-and-test` vive en este workflow y va a ser un check REQUERIDO. Un check requerido detras de un filtro `paths` nunca reporta en un PR que no toca esas rutas, y GitHub lee "no reporto" como "no satisfecho": el PR queda inmergeable para siempre, con todo lo visible en verde y nada a lo que apuntar. No es hipotetico ni en general ni aqui. `sdk-cli-ci.yml` lleva escrito que el repositorio lo vivio con `CodeQL SAST` en el PR #218, y por eso su `pull_request` no lleva filtro. Y medido sobre esta rama antes de tocar nada: el filtro listaba `src/sdk/cli/**`, `src/packages/**`, este fichero y `.harness/**`, mientras que el #690 solo toco `reference/` — habria sido el primero en clavarse. Se anade `branches: [main, develop]` para igualar la forma de `sdk-cli-ci.yml`: son las dos ramas protegidas, las unicas donde un check requerido decide algo. El filtro del `push` NO se toca: los pushes no pasan por checks requeridos, asi que ahi no hay deadlock posible y los minutos de CI valen la pena. Esa asimetria es el diseno, no un descuido. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
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 |
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.
Precondición registrada en
GT-710para poder requerirbuild-and-test.El defecto que evita
Un check requerido detrás de un filtro
pathsnunca reporta en un PR que no toca esas rutas, y GitHub lee «no reportó» como «no satisfecho»: el PR queda inmergeable para siempre, con todo lo visible en verde y nada a lo que apuntar.No es hipotético.
sdk-cli-ci.ymllleva escrito que el repositorio lo vivió conCodeQL SASTen el PR #218 — por eso supull_requestno lleva filtro. Y medido sobre esta rama antes de tocar nada: el filtro listabasrc/sdk/cli/**,src/packages/**, este fichero y.harness/**, mientras que #690 solo tocóreference/— habría sido el primero en clavarse.Qué cambia
pull_requestbranches: [main, develop]pushmain+ tagsv*El
branches: [main, develop]iguala la forma desdk-cli-ci.yml: son las dos ramas protegidas, las únicas donde un check requerido decide algo.El filtro del
pushno se toca a propósito: los pushes no pasan por checks requeridos, así que ahí no hay deadlock posible y los minutos de CI valen la pena. Esa asimetría es el diseño.Coste, dicho claro
El pipeline de release pasa a correr en todo PR a
mainodevelop, no solo en los que tocansrc/. Es el mismo trato que ya tienesdk-cli-ci.yml, y es lo que cuesta quebuild-and-testpueda bloquear.Una vez mergeado,
build-and-testya se puede añadir a los contextos requeridos.🤖 Generated with Claude Code