OnyxDanswer合并队列分诊指南用 GitHub GraphQL 精准查询 PR 真实入队状态与 main 预存 CI 失败【免费下载链接】danswerOpen Source AI Platform - AI Chat with advanced features that works with every LLM项目地址: https://gitcode.com/GitHub_Trending/da/danswer本篇指南围绕本仓库.cursor/skills/merge-dependabot-prs技能所附的 GraphQL 查询参考文档展开解决一个非常具体的工程痛点在由 GitHub Merge Queue 独家把关 main 分支的仓库中如何可靠地判断某个 PR 到底有没有在队列里以及某个失败的 CI 检查是不是 main 上本来就坏、与本次依赖升级无关。读完本文你将掌握两段可复制的gh api graphql查询模板、其结果解读矩阵以及它们在批量合并 Dependabot PR 时的完整落地流程。背景为什么mergeStateStatus与autoMergeRequest不可靠原文档开篇即点出核心问题mergeStateStatus和autoMergeRequest这两个字段单独看会滞后或产生误导can lag or mislead。它们描述的是 PR 侧的状态快照而合并队列是一个独立于 PR 的、串行执行的工作流——PR 可能因为各种原因被踢出队列例如 force-push 触发head_ref_force_pushed此时 PR 侧字段往往还停留在看起来正常的状态。在 OnyxDanswer仓库中这一点尤其关键因为 .cursor/skills/merge-dependabot-prs/SKILL.md 明确说明main分支只能通过合并队列合并Main Protection 规则集入队必须使用gh pr merge pr --auto且不能带--squash/--merge/--rebase策略参数队列自行决定合并方式带策略参数会被拒绝必需的检查包括quality-checks、playwright-required、database-tests、backend-check、mypy-check、Jest Tests、required其中required定义于 .github/workflows/pr-integration-tests.yml与playwright-required定义于 .github/workflows/pr-playwright-tests.yml是聚合了慢速集成测试 / Playwright 矩阵的needs: [...]if: always()收口 job。正因入队是一个独立状态SKILL.md 给出的建议与参考文档完全一致直接查询队列条目而不是猜 PR 侧字段。查询一读取 PR 在合并队列中的真实状态原文档给出的第一段查询用于回答这个 PR 现在到底在不在队列里、排在第几位gh api graphql -f query { repository(owner: onyx-dot-app, name: onyx) { pullRequest(number: PR_NUMBER) { isInMergeQueue mergeQueueEntry { position state } } } }使用前将PR_NUMBER替换为真实 PR 编号。如果你的仓库组织/仓库名不同同步替换owner与name本仓库技能面向的远端为 onyx-dot-app/onyx见 SKILL.md 元数据。关键字段解析字段类型含义pullRequest.isInMergeQueueBooleanPR 当前是否处于合并队列中是一个布尔开关pullRequest.mergeQueueEntryMergeQueueEntry | null队列条目对象为null表示不在队列里mergeQueueEntry.positionInt该 PR 在队列中的排位1 表示队首即将合并mergeQueueEntry.stateMergeQueueEntryState队列条目的状态常见取值如QUEUED排队中、WAITING等待前置条目等用于区分正在排队与卡住/异常结果解读矩阵原文档给出的判定逻辑非常明确mergeQueueEntry: null且isInMergeQueue: false→没有入队。原因分三类从未入队、force-push 后掉出队列、或者已经合并/关闭。区分最后一类需要单独再查 PR 的state字段如MERGED/CLOSED/OPENmergeQueueEntry非空 → 在队列中可进一步看position排位与state状态判断是正常排队还是出错需要干预。这一判定正是 SKILL.md 第 3 步Green: audit, approve, enqueue的配套动作gh pr merge pr --auto入队之后用本查询确认真的进队若 PR 因head_ref_force_pushedDependabot 自动 rebase 后常见掉队重跑一次gh pr merge pr --auto属于常规操作而非故障。查询二确认 CI 失败是否在 main 上预存面对一个红色检查第一反应不该是这个 PR 弄坏的而是先问main 当前的 HEAD 上同一个检查是不是也红着原文档的第二段查询回答了这个问题gh api graphql -f query { repository(owner: onyx-dot-app, name: onyx) { object(expression: main) { ... on Commit { checkSuites(first: 20) { nodes { checkRuns(first: 50, filterBy: {checkName: CHECK_NAME}) { nodes { name conclusion status } } } } } } } }将CHECK_NAME替换为目标检查名例如 SKILL.md 中列出的backend-check、mypy-check、Jest Tests等。查询结构拆解片段作用object(expression: main)取 main 分支当前的提交对象即最新 HEAD而非 PR 合入后的状态... on Commit内联片段只对 Commit 类型展开避免对其他 GitObject 子类型报错checkSuites(first: 20)取最近 20 个检查套件check suite覆盖最近的 CI 运行checkRuns(first: 50, filterBy: {checkName: CHECK_NAME})在每个套件内按名称过滤出目标检查的 runs每个套件最多取 50 个nodes { name conclusion status }只取名称、结论success/failure/…、状态completed/in_progress/…判定逻辑若 main 当前 HEAD 上同一个checkName显示相同的FAILUREconclusion: FAILURE则说明该失败是pre-existing预存——不是这个 PR 造成的反过来如果 main 上是绿的、只有 PR 分支红才进入PR 引入回归的怀疑队列需要进一步读失败 job 的日志定位根因。这段查询在 SKILL.md 第 6 步Needs diagnosis中对应Pre-existing分类同类 job 在 main 当前 HEAD 上也失败 → 不是这个 PR 的问题放着并明确说明。原文档特别强调了这个动作的先后顺序Before treating a failing check as caused by this PR——即先排除预存失败再定性为回归避免把 main 的历史债记到 Dependabot 升级头上。两张查询如何嵌入 merge-dependabot-prs 分诊流程参考文档是 SKILL.md 的配套引用文件原文档中两处链接均指向它。整个分诊流程可以概括为分桶 → 确认 → 逐个处理发现批次gh pr list --search is:open author:app/dependabot assignee:user拉出全部 Dependabot PR。仓库通过 .github/dependabot.yml 按生态打标签dependabot:python、dependabot:javascript、dependabot:docker、dependabot:actions以及沙箱相关的dependabot:sandbox并自动分配指派人分桶Green ready / Failing — mechanical生成的 lockfile 未重新生成/ Failing — needs diagnosis / Conflicting / Superseded。查询一负责核实Green桶是否真的在队列里查询二负责把needs diagnosis桶里的预存失败剥离出来绿灯流程gh pr checkout pr→ 激活仓库 venv →ods audit --fail-oncritical扫描bun.lock、uv.lock与开放的 Dependabot alerts非零退出即停止上报详见 tools/ods/README.md→gh pr review pr --approve→gh pr merge pr --auto机械性失败修复uv 升级后backend/requirements/*.txt过期 → 跑 CI 同款 pre-commit 钩子pre-commit run --files pyproject.toml uv.lock backend/requirements/*.txtbun 升级后bun.lock过期 → 在升级目录跑bun install跟踪到底用单一轮询循环同时盯队列状态与 PR 状态MERGED/CLOSED新失败出现即上报而不是静默等到成功——查询一正是这个循环里队列状态侧的事实来源。与仓库 CI 事实的对照上述工作流并非凭空设计本仓库的 CI 配置可以直接印证.github/workflows/merge-group.yml 提供了required与playwright-required两个**立即通过instant-pass**的桩 job专门服务于 merge_group 事件下的分支保护占位——这解释了为什么 SKILL.md 提醒若required/playwright-required从gh pr checks里消失说明矩阵还在跑PR 并未被阻塞.github/workflows/pr-integration-tests.yml 中requiredjob 通过needs: [changes, integration-tests, onyx-lite-tests, multitenant-tests]if: ${{ always() }}汇总整个集成测试矩阵的结果作为分支保护的单一稳定状态检查.github/workflows/audit.yml 在 PR 上以ods audit --fail-oncritical作为门禁且其paths触发条件覆盖bun.lock、uv.lock、pyproject.toml、.github/workflows/**、tools/ods/**——几乎每个 Dependabot PR 都会触发因此在 SKILL.md 中被视为该技能场景下的事实上的必需检查。理解了这些 job 的聚合与占位结构就能明白为何查询二里checkSuites(first: 20)要套件 按名过滤 run两层遍历聚合 job 的存在意味着同一检查名可能对应多个底层 run按checkName过滤才能把同名的这个检查在 main 上的表现完整捞出来。总结与最佳实践回到原文档两条最值得沉淀的工程结论判断是否入队永远直接查队列isInMergeQueuemergeQueueEntry { position state }是权威信号mergeStateStatus/autoMergeRequest只作参考两者矛盾时以队列条目为准。mergeQueueEntry: null只说明不在队列具体原因从未入队 / force-push 掉队 / 已合并关闭需配合 PR 的state字段二次确认定性 CI 失败先对照 main把同检查名在 main 当前 HEAD 上是否同样 FAILURE作为第一道分诊闸门能大幅减少把预存问题误判为 PR 回归的情况避免为强行让 CI 变绿而给无关源码打补丁。这两段查询模板.cursor/skills/merge-dependabot-prs/references/graphql-queries.md可以直接复制进任何以 GitHub Merge Queue 把关 main 的仓库把入队三连问进没进、排第几、什么状态和预存失败排查变成两条可复用的命令行肌肉记忆。【免费下载链接】danswerOpen Source AI Platform - AI Chat with advanced features that works with every LLM项目地址: https://gitcode.com/GitHub_Trending/da/danswer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考