Let's talk about the CI situation
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- node.js
- Área
- ci-cd, testing-qa
Línea de trabajo
No se nombran archivos fuente ni pruebas. Empieza leyendo esta discusión y el issue 3887 de nodejs/build al que se hace referencia; después, revisa el hilo de comentarios para encontrar una dirección acordada sobre la detección y el manejo de pruebas de CI inestables. Se consideraría terminado con un plan concreto y aceptado, no con un cambio de código específico.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
As of recently, especially with https://github.com/nodejs/build/issues/3887, dealing with the CI when preparing a release or when trying to land a PR has become very frustrating. I tried to list all the pain points, let me know if I forgot something:
- The CI is so flaky it's systematically takes several attempts to get a passing one.
- Most folks do not bother to check the failures.
- Even fewer folks are reporting flaky tests (I plead guilty).
- Even fewer folks are investigating those flakes (and I get it, the very nature of flaky tests makes them very hard to reproduce, let alone debugging them).
- Opening a PR to mark test(s) as flaky often receives objections that the flakiness should be solved instead of ignored (which I totally get, those flakes are most of the time due to a bug in
node; but it also makes the situation more frustrating for contributing, and also for other projects that build their own node and expect tests not marked as flaky to not be flaky).
I think we need to discuss:
- Is there a way to better detect flaky tests before landing them?
- How can we handle the immediate situation?
I'm opening this in the TSC repo, because it's kind of a meta discussion that I'm guessing is not going to be of much interest to folks following nodejs/node, but of course anyone is welcome to participate to the discussion.
- Lenguaje dominante
- JavaScript
- Estrellas
- 693
- Forks
- 142
- Merge medio
- 8 d 7 h
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin 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 nodejs/TSC
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 1/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 20/100
-
tsc-agenda
Dificultad 5/5 Más de una semana Aptitud para principiantes 8/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 3/100
-
build-agenda tsc-agenda
Dificultad 5/5 Más de una semana Aptitud para principiantes 5/100
Todos los issues de nodejs/TSC
Issues similares
-
FEATURE REQUEST
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
linuxmint/cinnamon-spices-extensions#1193 ·
Los mantenedores suelen responder en 1 día
-
ds-bot collides with dsh-argp: tool "recall" is already registered, Bot layer never activatesAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Fei2411/DeepSeek-Bot#703 ·
-
area:web first-timers-only good first issue
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
career-ops-hq/career-ops#6264 ·
Los mantenedores suelen responder en 1 día
-
[Server Submission]: Wiro AIAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 83/100
cline/mcp-marketplace#3394 ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
exelearning/exelearning#2677 ·
Los mantenedores suelen responder en 1 día