Stacked PR checks unrelated to the topmost PR are skipped
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 50/100
Línea de trabajo
Comienza rastreando cómo se seleccionan los workflows de CI para un stack publicado y reproduce el problema con dos PRs apilados que afectan a áreas no relacionadas del repositorio. Se considera terminado cuando cada PR del stack ejecuta los workflows relevantes para sus propios cambios, incluidos los PRs inferiores cuando el PR situado en la parte superior no los activa.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What happened
For a stack of pull requests, CI workflows are skipped when they are unrelated to the topmost PR in the stack, even if they are relevant to a lower PR.
Reproduction
- Configure separate CI workflows that run for changes to different parts of the repository.
- Create PR A from the trunk branch with a change that should trigger one of those workflows.
- Create PR B on top of A with an unrelated change that does not trigger that workflow.
- Publish A and B as a stack.
- Observe that the workflow relevant to PR A is skipped because it is unrelated to the topmost PR, PR B.
Expected behavior
Each PR in the stack should run the CI workflows relevant to its own changes.
Actual behavior
CI workflows are selected based on the topmost PR in the stack. Workflows unrelated to that PR are skipped across the stack, including workflows that are relevant to lower PRs.
Example consequence
PR A changes a database migration and should trigger migration tests. PR B adds an unrelated application change on top. If the migration workflow is unrelated to PR B, it is skipped, leaving PR A without the CI coverage relevant to its changes.
This is distinct from #319, where stale or missing merge refs prevent pull request workflows from running at all.
- Lenguaje dominante
- Go
- Estrellas
- 1.5k
- Forks
- 73
- Merge medio
- 1 d 8 h
- PR fusionados (30 d)
- 7
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de github/gh-stack
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
-
feature request topic: cli - general
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
feature request topic: auto-merge
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
bug topic: docs
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
Todos los issues de github/gh-stack
Issues similares
-
textual definition
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
geneontology/go-ontology#32653 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
-
needs design
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Priority/High ready-for-agent Severity/Major Type/Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100