Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Add merge queue CI optimisation

未关闭
#395 1 条评论 13 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
38/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
github, go
领域
cli, devtools

调研方向

没有指定文件或测试。首先定位 merge queue 的实现以及现有的 “Only merge non-failing pull requests” 选项，然后跟踪堆叠 PR 的评估方式。完成的标准是：排队中的 stack 只能在其最后一个 PR 上运行 CI，并以原子方式合并；同时，部分 queue 仍会在其最后一个排队 PR 成功时合并。

由索引模型根据 Issue 内容生成。

描述

feature request topic: merge queue

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":
Image

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.

主要语言
Go
星标
1.5k
派生
73
平均合并
1 天 8 小时
30 天内合并 PR
7

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

github/gh-stack 的其他 Issue

查看 github/gh-stack 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。