Add merge queue CI optimisation
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 38/100
Piste de recherche
Aucun fichier ni test n’est nommé. Commencez par localiser l’implémentation de la merge queue et l’option existante “Only merge non-failing pull requests”, puis suivez la manière dont les PRs empilées sont évaluées. Le travail est considéré comme terminé lorsqu’une pile en file d’attente peut exécuter la CI uniquement sur sa dernière PR et être fusionnée atomiquement, tandis qu’une file d’attente partielle est tout de même fusionnée lorsque sa dernière PR en file d’attente réussit.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
The problem
We use stacks a lot, and often mid stack PRs have some CI failures that are fixed above.
When I merge a stack of 5 PRs, I don't need to run CI in each of them, it's OK to skip 1-4 and only run CI in 5th. It saves A LOT of wasted runner minutes.
Current state
You have this checkbox "Only merge non-failing pull requests":
Imagine we have added 5 stacked PRs to a merge queue, with CI like this
PR 1 pass ✅
PR 2 pass ✅
PR 3 fail ❌
PR 4 pass ✅
PR 5 fail ❌
Checkbox set:
It will run CI on 5 pull requests, merge 1-2
Checkbox not set:
It will run CI on 5 pull requests, merge 1-4
Proposal
It is greedy to merge something now. I want it to merge a queued atomic stack instead.
In order to make it work, you need another checkbox "merge a queued stack atomically and only run CI on the last PR", where it will only run CI on PR 5, and it will not merge 1-2 or 1-4 of I queued 1-5.
However, if I only added 1-2 or 1-4 to the merge queue - it will merge, because the last queued PR succeeded.
For context: it is not rare for us to hit a 50 PRs limit in a graphite, and 20 PRs stacks are very usual. Saving 20x runner minutes is a huge deal.
- Langage dominant
- Go
- Étoiles
- 1.5k
- Forks
- 73
- Merge moyen
- 1 j 8 h
- PR mergées (30 j)
- 7
Guide de contribution
Ouvrir 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 github/gh-stack
-
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 92/100
-
feature request topic: cli - general
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
feature request topic: auto-merge
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
bug topic: docs
Difficulté 1/5 Moins d'une heure Accessibilité débutants 68/100
Toutes les issues de github/gh-stack
Issues similaires
-
area/dev-productivity area/disaster-recovery area/ipcei kind/enhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
kind/bug status/0-triage
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
🤔 refinement needed
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
equinor/radix-operator#1979 ·