Let's talk about the CI situation
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- node.js
- Ambito
- ci-cd, testing-qa
Direzione di ricerca
Non sono indicati file sorgente o test. Inizia leggendo questa discussione e l’issue 3887 di nodejs/build citata, quindi esamina il thread dei commenti per individuare una direzione concordata sul rilevamento e sulla gestione dei test CI intermittenti. Il lavoro sarebbe considerato completato con un piano concreto e accettato, non con una modifica specifica al codice.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- JavaScript
- Stelle
- 693
- Fork
- 142
- Merge medio
- 8g 7h
- PR unite (30g)
- 3
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di nodejs/TSC
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 1/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 20/100
-
tsc-agenda
Difficoltà 5/5 Più di una settimana Idoneità per principianti 8/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 3/100
-
build-agenda tsc-agenda
Difficoltà 5/5 Più di una settimana Idoneità per principianti 5/100
Issue simili
-
[guide] AGENTS.md claims the coverage gate, e2e and full lint run on every PR after ADR 0011 focused validationForse già presa @hivecommons-hive l’ha presa oggi. Apertaagent/guide documentation hive/claimed-by-guide stage/040-covered-by-pr
Difficoltà 2/5 1-3 ore Idoneità per principianti 81/100
cncf/endusers#2006 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
check:passed feeds:add
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 4 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
all-contributors/cli#587 ·
I maintainer di solito rispondono entro 1 giorno
-
RGAA5
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 8 giorni
-
feedback simulation workshop
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
githubnext/gh-aw-workshop#5157 ·
I maintainer di solito rispondono entro 1 giorno