Review pipeline-tooling changes under the copy the pipeline actually runs, not the PR's own copy
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 66/100
- Tipo de issue
- Documentación
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Área
- devtools
Línea de trabajo
El issue no nombra ningún archivo, así que primero busca dónde está documentado el método de revisión del repositorio y lee cómo trata actualmente los diffs de herramientas de CI o de pipeline. Añade la regla de que el revisor indique qué copia de la herramienta ejecuta la ejecución real y pruebe bajo esa copia, con el ejemplo del lock retenido para cualquier diff que vuelva a invocar una herramienta que toma un lock. Está terminado cuando el método de revisión contiene esta comprobación con ese ejemplo.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem. A PR that changes CI or pipeline tooling is usually verified with the PR's own copy of that tooling, but the pipeline often runs another copy: the base branch's pinned one. A change to a runner cannot fix the run that lands it, so a green self-check proves little.
Failure scenario. A pinned runner holds a non-reentrant file lock and calls a script the PR adds. That script re-invokes the runner, which waits on the same lock forever at 0% CPU until the run deadline. The PR's own precheck passed because it ran the PR's copy.
Proposed rule. For any diff touching pipeline tooling, state which copy the real run executes and test under that copy. If the diff spawns or re-invokes a lock-taking tool, test it with the lock held.
Done when. The review method lists this check with the lock-held example.
- Lenguaje dominante
- Python
- Estrellas
- 2
- Forks
- 1
- Merge medio
- 1 h 29 min
- PR fusionados (30 d)
- 567
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la 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 protocol/perun
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 64/100
Los mantenedores suelen responder en 1 día
Todos los issues de protocol/perun
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
adafruit/Fruit-Jam-OS#98 ·
-
python triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
microsoft/semantic-kernel#14753 ·
Los mantenedores suelen responder en 5 días
-
area:cli area:configuration documentation priority:low size:small
Dificultad 1/5 1-3 horas Aptitud para principiantes 80/100
RonaldHensbergen/composable-data-stack#1222 ·
Los mantenedores suelen responder en 1 día
-
bug python
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
pvlib/pvlib-python#2939 ·
Los mantenedores suelen responder en 1 día