sanguo/sanguo_moziplus_v2
8
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

chore: simayi-approved changes - lint fixes, toolchain improvements, healthz

Browse Source 
All changes reviewed and APPROVED in PR #12 (Review ID: 40):
- toolchain_routes: webhook repo/org format compat, content dedup (sha256), closed issue filter
- dispatcher: inform mail crash 误标 done 修复
- ticker: cleanup and improvements
- healthz endpoint
- conftest: integration/e2e deselect markers
- docs: design docs, test-guide updates
- various lint/whitespace fixes across 30 files
This commit is contained in:
cfdaily
2026-06-09 23:35:36 +08:00
parent a1a4d7c5a7
commit f7fbdac89c
30 changed files with 362 additions and 125 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/design/13-toolchain-and-dev-workflow.md
+16 -4
View File
@@ -1590,7 +1590,7 @@ daemon 内部 ───────┘ │ 5. 创建 Mail │
| 只处理白名单内的事件类型 | 未知的忽略 + 日志 |
| issue_comment 需判断来源 | 只处理 CI workflow 写的评论（按特定前缀匹配：`❌ **CI 失败**` 或统一后的 `[CI]` 前缀） |
| PR 作者/审查者必须是已知 Agent | 未知的忽略 + 日志 |
| 幂等：同一事件不重复创建 Mail | 按 `{x_gitea_event}-{x_gitea_delivery}` 去重（delivery ID 来自 `X-Gitea-Delivery` header） |
| 幂等：同一事件不重复创建 Mail | 双重去重：① delivery UUID（`{event}-{delivery}`）标准幂等；② review 事件 payload 内容去重（`{event}:{pr_num}:{sender}:{sha256(body_or_content)[:16]}`），防御同一 review 被不同来源重复提交（2026-06-09 新增） |
---
@@ -2007,6 +2007,9 @@ CI workflow 已有 `notify-on-failure` job（ci.yml），当前格式：
| 7 | 签名算法 | ✅ 已确认 | Gitea 使用 HMAC-SHA256，代码注释已补 |
| 8 | Webhook 作用范围 | ✅ 组织级 | Gitea 组织级 webhook（Hook ID=28），覆盖 sanguo 下所有仓库，新增仓库自动覆盖 |
| 9 | ALLOWED_HOST_LIST | ✅ 已修复 | Gitea 容器配置 `192.168.2.153, 127.0.0.1, localhost, 172.17.0.0/16, 192.168.2.0/24` |
| 10 | Gitea review payload 格式 | ✅ 姜维调研确认（2026-06-08） | Gitea v1.23.4 review payload 只有 `type` + `content`，没有 `state`/`body`/`user`，这不是 org vs repo 差异而是 Gitea 设计。v1.24.0 格式不变。双格式兼容是防御性编码，保持现状 |
| 11 | Spawner compact 检测窗口 | ✅ 已修复 | 窗口 300s→900s，尾部读取 50KB→1MB。实测长对话中 compact 记录被推出窗口导致漏检 |
| 12 | inform 类型 Mail crash 误标 done | ✅ 已修复 | `_mail_auto_complete` 增加 outcome 感知，inform 用白名单（completed/claimed/no_reply）控制 done 标记。spawner crash cooldown 300s→60s |
---
@@ -2713,10 +2716,10 @@ Gitea v1.23.4 自带完整的 CI 管理界面：
| # | 条件 | 状态 | 谁确认 |
|---|------|------|--------|
| 1 | act-runner 已注册且 label = `macos-arm64` | ✅ PM2 托管（sanguo-act-runner, id=44），崩溃自动重启 | 姜维确认 |
| 2 | Gitea repository secrets 已配置（CI_TOKEN） | ⚠️ 需确认 | 姜维 |
| 2 | Gitea repository secrets 已配置（CI_TOKEN） | ✅ 姜维确认（sanguo/moziplus-v2 已配 CI_TOKEN） | 姜维 |
| 3 | Gitea 组织级 Webhook 已启用（Hook ID=28） | ✅ 已确认 | 已确认 |
| 4 | 各 Agent 的 GITEA_TOKEN 环境变量 | ⚠️ 待分配 | 庞统协调 |
| 5 | main 分支保护规则（Review 才能 merge） | ⚠️ 需确认 | 姜维 |
| 4 | 各 Agent 的 GITEA_TOKEN 环境变量 | ✅ 已写入各 Agent TOOLS.md，姜维确认 token 记录存在 | 庞统+姜维 |
| 5 | main 分支保护规则（Review 才能 merge） | ✅ 姜维已配置（moziplus-v2 + sanguo_moziplus_v2，需1个approve） | 姜维 |
| 6 | 禁止在 daemon 运行时跑全量 E2E | ✅ 已警告司马懿 | 已确认 |
> 第 5 点很关键——如果 main 分支没有保护规则，开发者可以直接 push main 跳过 Review。
@@ -2753,3 +2756,12 @@ Gitea v1.23.4 自带完整的 CI 管理界面：
| §17.6.4 | 新增 P3 端到端验证结果（S1-S6 逐项） |
| §17.6.4 | 新增调研发现：Review API 枚举值、PullRequestReview webhook 支持、act-runner PM2 托管 |
| §17.10 | #1 状态更新：act-runner 已纳入 PM2 托管 |
### v3.1 → v3.2 变更（工具链修复 + Mail 投递 bug 修复）
| 编号 | 变更内容 |
|------|----------|
| §16.4 | Review handler 双格式兼容：HANDLERS 注册表同时注册 `pull_request_review` / `pull_request_approved` 等多种事件名；`_handle_pull_request_review` 兼容 repo webhook（review.state/body/user）和 org webhook（review.type/content/sender）两种 payload 格式 |
| §16.8 #10 | Gitea v1.23.4 review payload 调研结论（姜维 2026-06-08）：Gitea v1.23.4 review payload 只有 `type` + `content`，没有 `state`/`body`/`user`，这不是 org vs repo 差异而是 Gitea 设计。v1.24.0 格式不变。双格式兼容是防御性编码，保持现状 |
| §16.8 #11 | Spawner compact 检测窗口修复：窗口 300s→900s，尾部读取 50KB→1MB。实测长对话中 compact 记录被推出窗口导致漏检 |
| §16.8 #12 | inform 类型 Mail crash 误标 done bug 修复：`_mail_auto_complete` 增加 outcome 感知，inform 用白名单（completed/claimed/no_reply）控制 done 标记。spawner crash cooldown 300s→60s |
docs/design/18-toolchain-e2e-test.md
+121
View File
@@ -0,0 +1,121 @@
# §18. 工具链端到端验证测试
> 日期：2026-06-09
> 状态：已完成 ✅
> 目标：用真实 Webhook 触发验证整条 Mail 通知链路
## 前置确认
- Gitea 用户名 ↔ Agent ID 映射：完全一致（admin, guanyu-dev, jiangwei-infra, pangtong-fujunshi, simayi-challenger, zhangfei-dev, zhaoyun-data）
- Gitea 组织级 Webhook（Hook ID=28）：姜维确认最近 5 条投递全部 is_succeed=1
- Daemon 在线：sanguo-moziplus-v2 运行中
- 测试仓库：sanguo/moziplus-v2
## 命名规范
- Issue 标题：`[E2E-TEST] xxx`
- PR 标题：`[E2E-TEST] xxx`
- 分支名：`test/e2e-<timestamp>`
## 验证步骤
| 步骤 | 操作 | 触发事件 | 预期 Mail 通知 | 验证点 |
|------|------|----------|---------------|--------|
| 1 | 创建 Issue `[E2E-TEST] Issue指派测试`，assignee=zhangfei-dev | issues (assigned) | zhangfei-dev 收到 "Issue 指派" Mail | Mail to/模板正确 |
| 2 | 开分支 `test/e2e-<ts>`，创建 PR `[E2E-TEST] Review请求测试` | pull_request (opened) | simayi-challenger 收到 "Review 请求" Mail | Mail to/风险级别/文件列表 |
| 3 | PR Review APPROVED | pull_request_review (approved) | PR 作者(pangtong-fujunshi) 收到 "Review 通过 ✓" Mail | result=通过 ✓ |
| 4 | PR Review REQUEST_CHANGES | pull_request_review (rejected) | PR 作者收到 "Review 驳回 ✗" Mail | result=驳回 ✗ |
| 5 | Issue 上发评论 `[CI] CI 失败 — 分支: test/e2e-xxx, 错误: build timeout` | issue_comment | Issue 作者收到 "CI 失败" Mail | 模板含分支/错误摘要 |
| 6 | 创建标题含"部署失败"的 Issue（无指派） | issues (opened) | jiangwei-infra + pangtong-fujunshi 各收到 "部署失败" Mail | 双收件人 |
| 7 | 关闭步骤 1 的 Issue，再发 CI 失败评论 | issue_comment (closed issue) | 不产生 Mail（负面测试） | handler 跳过 closed |
| 8 | 重发步骤 1 Webhook（相同 delivery ID） | 重复事件 | 不产生新 Mail（幂等测试） | 返回 duplicate |
## 签名校验
已测试（GITEA_WEBHOOK_SECRET 已配置且生效）：
- ✅ 正确签名：请求正常处理
- ✅ 无签名：返回 403 `signature verification failed`
## Review 意见来源
- 姜维（基础设施确认 + 边界验证建议）
- 司马懿（遗漏点补充 + 命名规范 + 风险防范）
---
## 执行记录
> 2026-06-09 00:40~00:50 CST
### 步骤 1：Issue 指派 ✅
- 操作：创建 Issue #22 `[E2E-TEST] Issue指派测试`，assignee=zhangfei-dev
- Mail：`mail-1780936736480`，from=system, to=zhangfei-dev, title=`Issue 指派: [E2E-TEST] Issue指派测试`
- 模板渲染正确（含 Issue 链接、标签、描述、建议分支名）
### 步骤 2：PR Review 请求 ✅
- 操作：创建分支 `test/e2e-1780936838`，创建 PR #23
- Mail：`mail-1780936851715`，from=system, to=simayi-challenger
- 模板含 PR 链接、标题、作者(pangtong-fujunshi)、分支、风险级别(standard)
- 附带：CI 失败通知 `mail-1780936876572`（CI 自动触发，符合预期）
### 步骤 3：Review APPROVED ✅
- 操作：用 simayi-challenger token 提交 APPROVED review
- Mail：`mail-1780936968411`，from=system, to=pangtong-fujunshi, title=`Review 通过 ✓`
- 描述含审查者(simayi-challenger)、review body
- ⚠️ 收到 2 封重复 Mail（org webhook + repo webhook 双触发）
### 步骤 4：Review REQUEST_CHANGES ✅
- 操作：用 simayi-challenger token 提交 REQUEST_CHANGES review
- Mail：`mail-1780936972207`，from=system, to=pangtong-fujunshi, title=`Review 驳回 ✗`
- ⚠️ 同上，收到 2 封重复 Mail
### 步骤 5：CI 失败评论 ✅
- 操作：在 Issue #22 发评论 `[CI] CI 失败 — 分支: test/e2e-1780936838, 错误: build timeout`
- Mail：`mail-1780936994513`，from=system, to=pangtong-fujunshi, title=`CI 失败: sanguo/moziplus-v2#22`
- 模板含分支提取和错误摘要
### 步骤 6：部署失败 Issue ✅
- 操作：创建 Issue #24 `[E2E-TEST] 部署失败: test deploy`（无指派）
- Mail：`mail-1780936999660` to=jiangwei-infra, `mail-1780936999684` to=pangtong-fujunshi
- 双收件人验证通过 ✅
### 步骤 7：已关闭 Issue 负面测试 ✅
- 操作：关闭 Issue #22 后发 `[CI] CI 失败 — 应被过滤`
- 结果：未产生新 Mail ✅（只有步骤 5 的 1 封 CI Mail，步骤 7 的评论被正确过滤）
### 步骤 8：幂等测试 ✅
- 操作：构造带正确 HMAC-SHA256 签名的 Webhook，用同一 delivery ID `test-idempotency-002` 发两次
- 第一次：返回 `ok`，产生 Mail ✅
- 第二次：返回 `duplicate`，无新 Mail ✅
- 额外验证：不带签名的请求返回 403 `signature verification failed`（签名校验正常工作）
---
## 汇总
| 步骤 | 状态 | 备注 |
|------|------|------|
| 1. Issue 指派 | ✅ 通过 | Mail to/模板正确 |
| 2. PR Review 请求 | ✅ 通过 | Mail to/风险级别/文件列表正确 |
| 3. Review APPROVED | ✅ 通过 | E2E 测试中产生 2 封 Mail（根因已查明，非平台问题） |
| 4. Review REQUEST_CHANGES | ✅ 通过 | 同上 |
| 5. CI 失败评论 | ✅ 通过 | 分支提取正确 |
| 6. 部署失败 Issue | ✅ 通过 | 双收件人验证通过 |
| 7. 已关闭 Issue 过滤 | ✅ 通过 | 负面测试通过，无新 Mail |
| 8. 幂等测试 | ✅ 通过 | 第二次返回 duplicate，无新 Mail；签名校验正常拦截无签名请求 |
## 发现的问题
### Review 事件双 Mail（已修复）
- **现象**：E2E 测试步骤 3/4 中 Review 事件产生 2 封 Mail
- **根因**（姜维深入调查确认）：E2E 测试中庞统手动用 simayi token 提交了 Review，同时 simayi agent 收到 Review 请求 Mail 后也自主提交了 Review。是两次独立的 API 调用，**不是 Gitea bug 或平台配置问题**
- 姜维控制实验：一次 review API 调用只产生 1 个 hook_task
- Gitea 路由日志确认两次 POST 间隔 7 秒，payload 有差异（review_comments、updated_at 不同）
- 之前的错误分析（"Gitea webhookNotifier + actionsNotifier 双投递"）已被推翻：actionsNotifier 走 handleWorkflows() 不创建 hook_task
- **修复**：payload 内容去重作为防御性编程保留（`_is_duplicate` 新增内容去重 key = event + pr_num + sender + sha256(body_or_content)），司马懿 APPROVED
- **验证**：PR #27 实测只产生 1 封 Mail ✅
### 根因分析教训
- 姜维第一次分析给出了错误根因（Gitea 双 notifier），第二次深入调查后自我纠正
- 庞统把姜维的第一次结论当事实汇报给主公，没有标注"这是姜维的调查结论，尚未独立验证"
- **改进**：SOUL.md 新增规则——推测 vs 事实显式标注、引用他人结论时标注来源、结论被推翻时及时更正
docs/test-guide.md
+5 -4
View File
@@ -11,9 +11,10 @@
| 场景 | 命令 | 耗时 | 说明 |
|------|------|------|------|
| **改了某个模块** | `pytest tests/unit/test_spawner.py` | <5s | 只跑改动的模块对应的单元测试 |
| **改了 API 层** | `pytest tests/integration/` | ~1min | 跑全部集成测试 |
| **提交前快速验证** | `pytest -m "not e2e"` | ~2min | 不跑 E2E，验证不破坏现有功能 |
| **部署前全量验证** | `RUN_INTEGRATION=1 pytest` | ~60min | 含 E2E，真实 Agent |
| **改了 API 层** | `RUN_INTEGRATION=1 pytest tests/integration/` | ~1min | 跑全部集成测试 |
| **提交前快速验证** | `pytest` | ~2min | 默认排除 integration 和 e2e |
| **含集成测试** | `RUN_INTEGRATION=1 pytest` | ~5min | 包含 integration 测试 |
| **部署前全量验证** | `RUN_INTEGRATION=1 pytest` | ~60min | 含 e2e，真实 Agent |
| **只跑 E2E 场景** | `RUN_INTEGRATION=1 pytest tests/e2e/test_e2e_scenarios.py` | ~30min | 串行，一个跑完再下一个 |
| **只跑 E2E 压力** | `RUN_INTEGRATION=1 pytest tests/e2e/test_e2e_stress.py` | ~10min | 并发测试 |
@@ -101,7 +102,7 @@ E2E（慢，真实 Agent） → 验证完整链路，需要 RUN_INTEGRATION=1
## 关键规则
1. **只有 E2E 会 spawn 真实 Agent**，单元和集成不会
2. **不带 `RUN_INTEGRATION=1` 跑 `pytest` 是安全的**，E2E 全部 skip
2. **直接跑 `pytest` 是安全的**，integration 和 e2e 全部被排除（需 `RUN_INTEGRATION=1` 才跑）
3. **E2E 场景测试串行**，一个完成再下一个，失败要分析根因再继续
4. **E2E 压力测试并行**，场景测试全通过后再跑
5. **测试数据用 `e2e-` 前缀**，atexit 兜底清理，手动清理见上方