自动化与分类流程
本文档详细介绍了我们用于管理和分类问题(Issues)及拉取请求(Pull Requests)的自动化流程。我们的目标是提供及时的反馈,并确保贡献能够被高效地审查和集成。了解这些自动化机制将帮助你作为贡献者明确预期,并知道如何更好地与我们的仓库机器人交互。
指导原则:问题与拉取请求
首先,几乎每一个拉取请求(PR)都应关联到一个对应的问题(Issue)。问题描述“做什么”和“为什么做”(即 bug 或功能),而拉取请求则是“怎么做”(即实现方式)。这种分离有助于我们跟踪工作进度、优先处理功能,并保持清晰的历史背景。我们的自动化系统正是围绕这一原则构建的。
详细的自动化工作流
以下是我们仓库中运行的具体自动化工作流的分解说明。
1. 当你创建一个 Issue 时:自动化 Issue 分类
这是你在创建 Issue 时第一个交互的机器人。它的任务是进行初步分析并打上正确的标签。
- 工作流文件:
.github/workflows/qwen-automated-issue-triage.yml - 运行时机:在 Issue 创建或重新打开后立即运行。
- 功能说明:
- 使用 Qwen 模型根据详细的指导原则分析 Issue 的标题和正文内容。
- 应用一个
area/*标签:将 Issue 归类到项目的某个功能领域(例如area/ux、area/models、area/platform)。 - 应用一个
kind/*标签:识别 Issue 的类型(例如kind/bug、kind/enhancement、kind/question)。 - 应用一个
priority/*标签:根据描述的影响程度分配优先级,从 P0(严重)到 P3(低)。 - 可能添加
status/need-information:如果 Issue 缺少关键信息(如日志或复现步骤),它会被标记需要更多信息。 - 可能添加
status/need-retesting:如果 Issue 中提到的 CLI 版本比当前最新版本落后超过六个版本,则会标记为需使用当前版本重新测试。
- 你应该做什么:
- 尽可能完整地填写 Issue 模板。提供的细节越多,分类就越准确。
- 如果被添加了
status/need-information标签,请在评论中提供所需的信息。
2. 当你打开一个 Pull Request 时:持续集成(CI)
此工作流程确保所有更改在合并之前都符合我们的质量标准。
- 工作流文件:
.github/workflows/ci.yml - 运行时机:每次向 Pull Request 推送代码时。
- 执行内容:
- Lint:检查你的代码是否遵循项目的格式和样式规则。
- Test:在 macOS、Windows 和 Linux 上,以及多个 Node.js 版本上运行全套自动化测试。这是 CI 流程中最耗时的部分。
- Post Coverage Comment:在所有测试成功通过后,机器人会在你的 PR 下发布一条评论。该评论总结了你的更改被测试覆盖的情况。
- 你应该做什么:
- 确保所有 CI 检查都通过。当一切成功时,提交旁边会出现绿色勾号 ✅。
- 如果某个检查失败(红色“X”❌),请点击失败检查旁边的“Details”链接查看日志,找出问题并推送修复。
3. 持续的 Pull Request 分类管理:PR 审查与标签同步
此工作流会定期运行,以确保所有开放的 PR 都正确关联了问题,并且标签保持一致。
- 工作流文件:
.github/workflows/qwen-scheduled-pr-triage.yml - 运行时机:每 15 分钟对所有开放的 Pull Request 运行一次。
- 功能说明:
- 检查是否关联了问题:机器人会在你的 PR 描述中扫描用于链接到问题的关键字(例如
Fixes #123、Closes #456)。 - 添加
status/need-issue标签:如果没有找到关联的问题,机器人将为你的 PR 添加status/need-issue标签。这是一个明确信号,表示需要创建并链接一个相关问题。 - 同步标签:如果已关联问题,机器人会确保该 PR 的标签与所关联问题的标签完全匹配。它会添加缺失的标签,移除不属于当前情况的标签,并在必要时移除
status/need-issue标签。
- 检查是否关联了问题:机器人会在你的 PR 描述中扫描用于链接到问题的关键字(例如
- 你应该怎么做:
- 始终将你的 PR 关联到一个问题。这是最重要的一步。请在 PR 描述中加入类似
Resolves #<issue-number>的内容。 - 这样可以确保你的 PR 被正确分类,并顺利进入代码审查流程。
- 始终将你的 PR 关联到一个问题。这是最重要的一步。请在 PR 描述中加入类似
4. 持续问题分诊:定时问题分诊
这是一个备用工作流程,用于确保没有问题被分诊过程遗漏。
- 工作流文件:
.github/workflows/qwen-scheduled-issue-triage.yml - 运行时间:每小时运行一次,针对所有未关闭的问题。
- 功能说明:
- 主动查找没有任何标签或仍带有
status/need-triage标签的问题。 - 然后触发与初始分诊机器人相同的基于 QwenCode 的强大分析功能,以应用正确的标签。
- 主动查找没有任何标签或仍带有
- 你应该做什么:
- 通常你不需要做任何事情。此工作流程是一个安全网,确保即使初始分诊失败,每个问题最终也会被分类。
5. 发布自动化
此工作流负责打包和发布 Qwen Code 的新版本。
- 工作流文件:
.github/workflows/release.yml - 运行时机:按每日计划执行“夜间”版本发布,以及手动触发正式的补丁/次要版本发布。
- 功能说明:
- 自动构建项目、递增版本号,并将包发布到 npm。
- 在 GitHub 上创建对应的发布版本,并自动生成发布说明。
- 你需要做什么:
- 作为贡献者,你无需为此流程做任何操作。你可以放心,一旦你的 PR 被合并到
main分支,你的更改将会包含在下一个夜间版本中。
- 作为贡献者,你无需为此流程做任何操作。你可以放心,一旦你的 PR 被合并到
我们希望这份详细的概述对你有所帮助。如果你对我们的自动化流程有任何疑问,请随时提出!
Last updated on