Skip to Content
开发者指南Development问题和 PR 自动化

自动化与分类流程

本文档详细介绍了我们用于管理和分类问题(Issues)及拉取请求(Pull Requests)的自动化流程。我们的目标是提供及时的反馈,并确保贡献能够被高效地审查和集成。了解这些自动化机制将帮助你作为贡献者明确预期,并知道如何更好地与我们的仓库机器人交互。

指导原则:问题与拉取请求

首先,几乎每一个拉取请求(PR)都应关联到一个对应的问题(Issue)。问题描述“做什么”和“为什么做”(即 bug 或功能),而拉取请求则是“怎么做”(即实现方式)。这种分离有助于我们跟踪工作进度、优先处理功能,并保持清晰的历史背景。我们的自动化系统正是围绕这一原则构建的。


详细的自动化工作流

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

1. 当你创建一个 Issue 时:自动化 Issue 分类

这是你在创建 Issue 时第一个交互的机器人。它的任务是进行初步分析并打上正确的标签。

  • 工作流文件.github/workflows/qwen-automated-issue-triage.yml
  • 运行时机:在 Issue 创建或重新打开后立即运行。
  • 功能说明
    • 使用 Qwen 模型根据详细的指导原则分析 Issue 的标题和正文内容。
    • 应用一个 area/* 标签:将 Issue 归类到项目的某个功能领域(例如 area/uxarea/modelsarea/platform)。
    • 应用一个 kind/* 标签:识别 Issue 的类型(例如 kind/bugkind/enhancementkind/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 #123Closes #456)。
    • 添加 status/need-issue 标签:如果没有找到关联的问题,机器人将为你的 PR 添加 status/need-issue 标签。这是一个明确信号,表示需要创建并链接一个相关问题。
    • 同步标签:如果已关联问题,机器人会确保该 PR 的标签与所关联问题的标签完全匹配。它会添加缺失的标签,移除不属于当前情况的标签,并在必要时移除 status/need-issue 标签。
  • 你应该怎么做
    • 始终将你的 PR 关联到一个问题。这是最重要的一步。请在 PR 描述中加入类似 Resolves #<issue-number> 的内容。
    • 这样可以确保你的 PR 被正确分类,并顺利进入代码审查流程。

4. 持续问题分诊:定时问题分诊

这是一个备用工作流程,用于确保没有问题被分诊过程遗漏。

  • 工作流文件.github/workflows/qwen-scheduled-issue-triage.yml
  • 运行时间:每小时运行一次,针对所有未关闭的问题。
  • 功能说明
    • 主动查找没有任何标签或仍带有 status/need-triage 标签的问题。
    • 然后触发与初始分诊机器人相同的基于 QwenCode 的强大分析功能,以应用正确的标签。
  • 你应该做什么
    • 通常你不需要做任何事情。此工作流程是一个安全网,确保即使初始分诊失败,每个问题最终也会被分类。

5. 发布自动化

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

  • 工作流文件.github/workflows/release.yml
  • 运行时机:按每日计划执行“夜间”版本发布,以及手动触发正式的补丁/次要版本发布。
  • 功能说明
    • 自动构建项目、递增版本号,并将包发布到 npm。
    • 在 GitHub 上创建对应的发布版本,并自动生成发布说明。
  • 你需要做什么
    • 作为贡献者,你无需为此流程做任何操作。你可以放心,一旦你的 PR 被合并到 main 分支,你的更改将会包含在下一个夜间版本中。

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

Last updated on