Let's talk about the CI situation
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
- Type d'issue
- Fonctionnalité
- Clarté
- À clarifier
- Activité
- À l'abandon
- Stack technique
- node.js
- Domaine
- ci-cd, testing-qa
Piste de recherche
Aucun fichier source ni test n’est indiqué. Commencez par lire cette discussion et l’issue 3887 de nodejs/build mentionnée, puis examinez le fil de commentaires pour trouver une orientation approuvée concernant la détection et la gestion des tests CI instables. La tâche serait considérée comme terminée avec un plan concret et accepté, et non avec une modification de code spécifique.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- JavaScript
- Étoiles
- 693
- Forks
- 142
- Merge moyen
- 8 j 7 h
- PR mergées (30 j)
- 3
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de nodejs/TSC
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 1/100
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 20/100
-
tsc-agenda
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 8/100
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 3/100
-
build-agenda tsc-agenda
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 5/100
Toutes les issues de nodejs/TSC
Issues similaires
-
[Feature Request] [Web] Expose kvCacheQuantizationBits in the onnxruntime-web WebGPU EP optionsOuverteep:WebGPU platform:web quantization
Difficulté 2/5 1-3 heures Accessibilité débutants 66/100
microsoft/onnxruntime#33752 ·
Les mainteneurs répondent en général sous 2 jours
-
More Transport Mode IconsOuverteicon request
Difficulté 2/5 1-3 heures Accessibilité débutants 66/100
tabler/tabler-icons#1693 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 1-3 heures Accessibilité débutants 72/100
alvarotrigo/fullPage.js#4755 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
jlab-sensing/ENTS-backend#854 ·
-
enhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
andromarces/agent-loops#1242 ·
Les mainteneurs répondent en général sous 1 jour