ci: add Mergify conflict detection and DCO nudges - #5082
Conversation
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Request changes conclusion (author-owned PR; GitHub blocks formal self-review)
评审 head：d5a949d27a55a1f1d881287383c0741f2325aef5；不可变基线：a23e08175f38286682eabcf15b41a6bc439954ed。
动机
PR 希望把冲突发现和 DCO 修复提示交给 Mergify，减少贡献者反复等待维护者提醒。它属于 #4574 的 S12 开发者协作维护，scope 限于 label/comment。这个目的合理；不过“App 已安装、配置合法”还没有证明提醒会执行。
改动思路
.github/mergify.yml 是本仓库采用的受支持配置位置。三个独立规则分别处理开放 PR 的 conflict、解除 conflict 后清理标签、非 draft 开放 PR 的 Sign-off 失败；条件由 Mergify 的原生 rule engine 持有，评论中的命令只是贡献者建议。没有 merge、queue、rebase、review 或权限提升 action。配置从默认分支读取，PR head 中的文件本身还不会启用线上规则。Mergify 配置契约
具体改动
- 第 8–29 行 conflict 规则用
conflict && !closed添加needs-rebase并渲染 base/author 的修复评论。 - 第 31–38 行清理规则用
!conflict && !closed移除同一个标签；与添加条件互斥，避免两个规则争抢标签。 - 第 40–51 行 DCO 规则用
check-failure=Sign-off && !closed && !draft建议 amend/signoff。当前工作流的 job 名确实是Sign-off，但失败结论并不等同于“缺少 trailer”。
[P1] 启用 Workflow Automation 才能交付提醒（配置第 7 行的整体执行前置条件）。 我只读检查了仓库的 Workflow Automation 页面，页面仍提供 Activate Workflow Automation，没有启用后的规则界面。官方契约明确规定：未启用 Workflow Automation 时，pull_request_rules 合法但完全不被评估；绿色配置校验不能证明动作会发生。因而合入这个文件后，当前产品设置下冲突/DCO 提醒仍不会执行。请由有权维护者确认并启用这个产品，在默认分支配置生效后给出一次真实冲突加标签/评论和解除后的清理回读；若当前只能交付预备配置，请明确这一未交付边界、启用 owner 和恢复条件，不把 editor 的 “valid” 当作自动提醒的验收。该问题不是远端 CI 是否通过。官方“Sections That Are Never Used”说明
[P2] fork 的恢复建议使用了错误 remote（第 23–25 行）。 标准 fork clone 中，origin 指向贡献者 fork，origin/main 可以落后于 PR 的上游 base。实际合成 Git 仓库复现：上游推进制造冲突后，执行这里的 fetch/rebase/push 全部成功，PR branch head 不变，上游 merge-tree 仍冲突；改为 fetch/rebase upstream/main 才真正暴露需要解决的冲突。请区分同仓库和 fork，指明 upstream 指向 base repository，再重放完整恢复旅程。尾部外链不会纠正可直接复制的错误命令。GitHub fork 同步指南
[P2，非阻塞建议] DCO 评论不要把所有 check-failure 归因于缺 trailer（第 43/49–51 行）。 该条件还匹配 cancelled/timed_out/action_required；现有 Sign-off job 的 checkout/fetch 本身也可能失败。建议忽略 cancelled，评论先让作者检查失败详情，只在日志确认缺失 trailer 时建议重写提交。无需新增 DCO 判断引擎。Mergify condition 定义
对主干的风险
我读完唯一配置 diff，扫描现有 Mergify/needs-rebase/DCO/workflow 入口，没有其他抢占配置或标签的规则。以当前官方 schema（Git blob 613a5fbc19840e72e873bc743175b788b118e899）校验通过；三个规则的结构和 action 范围有效，base/author 模板可渲染，仓库标签已存在。配置专属 canary 的三个直接检查和公开边界检查通过；PR 的 commit 有 DCO trailer。没有获取、轮询或等待远端 CI。
正常路径的设计符合原生 conflict 条件和互斥标签规则，但当前产品尚未启用，不能声称已验证真实评论发布、条件恢复、重复事件的动作幂等或新 PR 的覆盖。只读 configuration-simulator API 返回 403，因此没有把模拟成功写入证据，也没有通过新授权或点击 Activate 改变设置。实际 Git fork 负例验证了修复命令的行为；schema/template 校验无法替代它。
默认变化是合入后、产品启用时对本仓库开放 PR 自动增删标签及发表评论；安装 App、接受合法文件或存在标签均不代表产品启用，更不赋予合并/审批权限。Mergify 的原生 edge-trigger 设计有助于避免每个事件重发同一评论，但当前仓库上的多轮恢复仍需真实回读。回退可以删除这份配置或由维护者禁用 Workflow Automation。没有 frontend/Lark/LoopX CLI companion 变更：这是 GitHub 仓库协作入口的配置，不改变 Goal 或产品 UI。
我的整体评价
REQUEST_CHANGES，主要因为实际执行前置条件缺失，预期的自动提醒尚未建立；fork 命令还会让受影响贡献者得到“操作成功但冲突仍在”的恢复体验。最小修复是补齐产品启用与真实回读、修正 remote 指导，不需要引入新运行时代码或扩展规则规模。
未来变化准备检查认为当前三条规则足够小，继续复用 Mergify 原生条件/动作即可；不需要在 LoopX 新建 PR-monitor 引擎。规则执行是机器行为，评论建议是人工选择，DCO 与合并义务仍由现有仓库策略执行。配置可以独立回退，但这份评审没有授予产品启用、额外权限或合并授权。
English verdict: REQUEST_CHANGES - head d5a949d. Workflow Automation is inactive, so valid pull_request_rules will not execute; fork origin/main instructions also fail to advance to the upstream base. Official schema/template and local config checks passed; real Git reproduction confirms the fork recovery gap. Live comment/label recovery remains unverified.
413d4e0 to
420217e
Compare
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
动机
复核完整 PR 与上次 review 后的修复，当前 head 420217e4ac9ef84c45cb78ba25b66fab99e5375f。没有剩余 blocking finding；上次三项问题均已修复。目标是让贡献者实际收到可执行的冲突/DCO 提示。最有力的反例是「配置有效却未启用」以及「fork 中 rebase 成功却仍有冲突」；本次分别经过真实服务和真实 Git 验证。
改动思路
复用 Mergify 原生 pull_request_rules、现有 needs-rebase 标签及 Actions Sign-off，保留三条规则。只授权评论和标签动作；merge、approve、queue 仍由维护者负责。相较另建轮询器或冲突状态存储，这个边界更小且可直接禁用回滚。
具体改动
- 通过 Ego Lite 在官方控制台实际启用 loopx 仓库的 Workflow Automation，刷新后启用状态仍保留。安装 App 与合法 YAML 本身不会启用动作；文件头已说明开启与停用方式。
.github/mergify.yml:11使用 GitHub 的conflict/-closed添加标签与提醒；:46在冲突解除后移除标签。提醒使用实际 base/author，fork 从真正的upstream获取 base；同仓库 clone 可使用origin。:55绑定@github-actions/Sign-off，忽略 cancelled、closed、draft。先查看任务详情，只有日志确认缺少 trailer 才建议 amend/rebase；超时和基础设施错误不会被写成缺少签名。- 当前配置在官方 schema 和官方编辑器均有效；实际 #3200（冲突且非 main base）、#5082（无冲突）、#5083（已关闭）分别命中正确条件，模板正确替换 base/author。
- 相同真实 Git fixture 中，旧 fork 提示命令退出 0 但 upstream 不是祖先、冲突仍在；修复后 fork/同仓库两条路径均能解决冲突、推送并保留每个 DCO trailer。
现有 DCO workflow 测试 11 passed。当前最终 diff 的标准 premerge 通过 3 项 diff 检查 + 1 项公共边界检查，严格 change-quality receipt 已验证。此配置范围没有选中其他 catalog/profile 检查。未查询或等待远程 CI，符合当前 review policy。后续维护性检查已应用在原有规则内：限定检查身份、统一 base remote 提示，没有新增抽象或永久临时 probe。
对主干的风险
启用后，符合条件的现有及未来 PR 会自动收到评论/标签，这是明确披露的行为变化；不会改变合并权限或 LoopX 运行时。配置只有默认分支部署后才执行，因此编辑器的非执行验证不等于线上机器人动作已通过。合并后的同一任务将创建隔离的签名临时 PR，验证实际评论、标签、去重与冲突恢复，再关闭 PR、删除本任务临时 refs；这是默认分支部署的后续验收边界，不是遗漏的实现。可随时关闭 Workflow Automation 或移除此文件停止规则。
我的整体评价
完整三规则部署范围与问题相称，复用了现有服务和 DCO 判定，修复了上次的启用、fork 恢复及错误诊断问题。配置/真实 Git 的部署前证据足以批准该独立可回滚部署；整项任务仍须完成上述线上 readback。原生 comment 的重复抑制与实际标签清理是最强的剩余部署验收，尚不宣称通过。
English verdict: APPROVE - 420217e4ac9ef84c45cb78ba25b66fab99e5375f. No blocking findings remain; the selected repository product is enabled, native rules validate and real fork/same-repository recovery passes. Live bot effects and cleanup are explicitly verified after default-branch deployment.
Keep conflict labels and contributor reminders in Mergify's native rules. Explain product activation and rollback, fetch the base repository for fork recovery, and restrict DCO nudges to non-cancelled GitHub Actions Sign-off failures without assuming every failure means an unsigned commit. Co-authored-by: Cursor <cursoragent@cursor.com> Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
420217e to
ff5ed05
Compare
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
动机
复核完整 PR 与上次 review 后的修复，当前 head ff5ed05b0ae9f991f806f5d62f0afc79f6f5d234。没有剩余 blocking finding；上次三项问题均已修复。目标是让贡献者实际收到可执行的冲突/DCO 提示。最有力的反例是「配置有效却未启用」以及「fork 中 rebase 成功却仍有冲突」；本次分别经过真实服务和真实 Git 验证。
改动思路
复用 Mergify 原生 pull_request_rules、现有 needs-rebase 标签及 Actions Sign-off，保留三条规则。只授权评论和标签动作；merge、approve、queue 仍由维护者负责。相较另建轮询器或冲突状态存储，这个边界更小且可直接禁用回滚。
具体改动
- 通过 Ego Lite 在官方控制台实际启用 loopx 仓库的 Workflow Automation，刷新后启用状态仍保留。安装 App 与合法 YAML 本身不会启用动作；文件头已说明开启与停用方式。
.github/mergify.yml:11使用 GitHub 的conflict/-closed添加标签与提醒；:46在冲突解除后移除标签。提醒使用实际 base/author，fork 从真正的upstream获取 base；同仓库 clone 可使用origin。:55绑定@github-actions/Sign-off，忽略 cancelled、closed、draft。先查看任务详情，只有日志确认缺少 trailer 才建议 amend/rebase；超时和基础设施错误不会被写成缺少签名。- 当前配置在官方 schema 和官方编辑器均有效；实际 #3200（冲突且非 main base）、#5082（无冲突）、#5083（已关闭）分别命中正确条件，模板正确替换 base/author。
- 相同真实 Git fixture 中，旧 fork 提示命令退出 0 但 upstream 不是祖先、冲突仍在；修复后 fork/同仓库两条路径均能解决冲突、推送并保留每个 DCO trailer。
现有 DCO workflow 测试 11 passed。当前最终 diff 的标准 premerge 通过 3 项 diff 检查 + 1 项公共边界检查，严格 change-quality receipt 已验证。此配置范围没有选中其他 catalog/profile 检查。未查询或等待远程 CI，符合当前 review policy。后续维护性检查已应用在原有规则内：限定检查身份、统一 base remote 提示，没有新增抽象或永久临时 probe。
对主干的风险
启用后，符合条件的现有及未来 PR 会自动收到评论/标签，这是明确披露的行为变化；不会改变合并权限或 LoopX 运行时。配置只有默认分支部署后才执行，因此编辑器的非执行验证不等于线上机器人动作已通过。合并后的同一任务将创建隔离的签名临时 PR，验证实际评论、标签、去重与冲突恢复，再关闭 PR、删除本任务临时 refs；这是默认分支部署的后续验收边界，不是遗漏的实现。可随时关闭 Workflow Automation 或移除此文件停止规则。
我的整体评价
完整三规则部署范围与问题相称，复用了现有服务和 DCO 判定，修复了上次的启用、fork 恢复及错误诊断问题。配置/真实 Git 的部署前证据足以批准该独立可回滚部署；整项任务仍须完成上述线上 readback。原生 comment 的重复抑制与实际标签清理是最强的剩余部署验收，尚不宣称通过。
English verdict: APPROVE - ff5ed05b0ae9f991f806f5d62f0afc79f6f5d234. No blocking findings remain; the selected repository product is enabled, native rules validate and real fork/same-repository recovery passes. Live bot effects and cleanup are explicitly verified after default-branch deployment.
|
Deployment and live-readback update for the reviewed #5082 configuration.
The GitHub contributor journey owns this configuration; no LoopX frontend, Lark or CLI companion change is required. Provider follow-up: the repository owner authorized the prepared reproduction report, and it was submitted through the native Mergify Problem form on 2026-09-26T16:59:39.892Z. The dialog closed after submission; no ticket identifier was displayed. Standalone branch-update-event acceptance still awaits provider diagnosis. |
1 participant
Mergify adds contributor reminders when a pull request conflicts with its current base, removes
needs-rebasewhen reevaluated as clean, and gives diagnostic guidance for a failed GitHub ActionsSign-offcheck. Fork recovery fetches the actual base repository rather than a stale fork; DCO advice distinguishes infrastructure failures from missing trailers and excludes cancelled checks.Only
.github/mergify.ymlchanges: three native comment/label rules. Workflow Automation was enabled for the selectedloopxrepository through the official dashboard and persisted across refresh. Disable that product or remove the file to stop the rules.Validation passed: official Mergify schema and real configuration editor; real Git fork/same-repository conflict recovery with DCO retention; 11 DCO workflow tests; standard premerge diff/public-boundary checks; exact-scope change-quality receipt. Exact-head review was published before merge. No remote CI polling under the current review policy.
Real deployment readback passed on disposable PRs: refresh-driven comment/label/dedup/recovery on #5122, plus ordinary PR-event comment/label and recovery metadata-event cleanup on #5129 without any refresh command. However, standalone branch-update triggering remains unqualified: a signed recovery push did not clean the label during 214 seconds, while a later metadata edit did; a second conflict push produced no effect during 202 seconds. Provider webhook/state-refresh diagnosis remains necessary; its cause is not established. The official
@mergifyio refreshcommand is a verified fallback. All disposable PRs are closed and their owned temporary branches/worktrees removed.Full passed/pending readback: #5082 (comment)
The GitHub contributor journey owns this behavior; no LoopX frontend, Lark or CLI configuration change is required.