自动化与分类流程

本文档详细概述了我们用于管理和分类 Issue 及 Pull Request 的自动化流程。我们的目标是及时提供反馈，并确保贡献能被高效地审查和合并。了解这些自动化机制将帮助你作为贡献者知道预期会发生什么，以及如何最好地与我们的仓库机器人互动。

指导原则：Issue 与 Pull Request

首先，几乎每个 Pull Request（PR）都应该关联一个对应的 Issue。Issue 描述“做什么”和“为什么”（即 Bug 或功能），而 PR 则是“怎么做”（即实现）。这种分离有助于我们跟踪工作、确定功能优先级，并保持清晰的历史上下文。我们的自动化正是基于这一原则构建的。

详细的自动化工作流

以下是我们在仓库中运行的具体自动化工作流分解。

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 过程中最耗时的部分。
  • 发布覆盖率评论：所有测试成功通过后，机器人会在你的 PR 上发布一条评论，总结你的变更被测试覆盖的程度。
• 你应该做什么：
  • 确保所有 CI 检查通过。当一切成功时，你的提交旁边会出现一个绿色勾 ✅。
  • 如果检查失败（红色“X” ❌），请点击失败检查旁的“Details”链接查看日志，找出问题并推送修复。

3. Pull Request 的持续分类：PR 审计与标签同步

此工作流定期运行，确保所有开放的 PR 都正确链接到 Issue 并具有一致的标签。

• 工作流文件：.github/workflows/qwen-scheduled-pr-triage.yml
• 触发时机：每 15 分钟对所有开放的 Pull Request 执行一次。
• 执行内容：
  • 检查链接的 Issue：机器人扫描你的 PR 描述，查找将其链接到 Issue 的关键词（例如 Fixes #123、Closes #456）。
  • 添加 status/need-issue：如果未找到链接的 Issue，机器人会为你的 PR 添加 status/need-issue 标签。这是一个明确的信号，表明需要创建并关联一个 Issue。
  • 同步标签：如果确实链接了 Issue，机器人会确保 PR 的标签与 Issue 的标签完全匹配。它会添加任何缺失的标签，并移除不相关的标签；如果之前存在 status/need-issue 标签，也会将其移除。
• 你应该做什么：
  • 始终将你的 PR 链接到一个 Issue。 这是最重要的一步。请在 PR 描述中添加一行如 Resolves #<issue-number> 的内容。
  • 这样做将确保你的 PR 得到正确分类，并顺利通过审查流程。

4. Issue 的持续分类：定期 Issue 分类

这是一个兜底工作流，确保没有 Issue 被分类流程遗漏。

• 工作流文件：.github/workflows/qwen-scheduled-issue-triage.yml
• 触发时机：每小时对所有开放的 Issue 执行一次。
• 执行内容：
  • 主动查找那些没有标签或仍带有 status/need-triage 标签的 Issue。
  • 然后触发与初始分类机器人相同的基于 QwenCode 的强大分析，以应用正确的标签。
• 你应该做什么：
  • 通常你不需要做任何事。此工作流是一个安全网，确保每个 Issue 最终都会被分类，即使初始分类失败了。

5. 发布自动化

此工作流负责打包和发布 Qwen Code 的新版本。

• 工作流文件：.github/workflows/release.yml
• 触发时机：对于“夜间”版本按每日计划运行；对于正式补丁/次要版本则手动触发。
• 执行内容：
  • 自动构建项目，提升版本号，并将包发布到 npm。
  • 在 GitHub 上创建对应的发布版本，并生成发布说明。
• 你应该做什么：
  • 作为贡献者，你无需对此流程做任何操作。请放心，一旦你的 PR 被合并到 main 分支，你的变更将包含在下一个夜间版本中。

我们希望这份详细的概述对你有帮助。如果你对我们的自动化或流程有任何疑问，请随时提出！