自动化和分类处理流程

自动化和分类处理流程

本文档详细介绍了我们用于管理和分类问题及拉取请求的自动化流程。我们的目标是提供及时的反馈，并确保贡献能够得到有效审查和集成。了解这些自动化流程将帮助您作为贡献者了解预期的情况以及如何与我们的仓库机器人最佳互动。

指导原则：问题和拉取请求

首先，几乎每一个拉取请求（PR）都应该关联一个相应的问题。问题描述了“是什么”和“为什么”（即错误或功能），而PR则是“怎么做”（即实现方法）。这种分离有助于我们跟踪工作，优先处理功能，并保持清晰的历史背景。我们的自动化就是围绕这一原则构建的。

**注意：**标记为“🔒仅限维护者”的问题是为项目维护者保留的。我们将不接受与这些问题相关的拉取请求。

---

详细的自动化工作流程

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

1. 当您打开一个问题时：Automated Issue Triage

这是您在创建问题时将首先与之互动的机器人。其任务是执行初步分析并应用正确的标签。

工作流程文件：.github/workflows/gemini-automated-issue-triage.yml

运行时机：在问题创建或重新打开后立即运行。

功能描述：

• 它使用 Gemini 模型对问题的标题和正文根据一系列详细指南进行分析。
• 应用一个area/*标签：将问题归类到项目的功能区域（例如，area/ux，area/models，area/platform）。
• 应用一个kind/*标签：识别问题的类型（例如，kind/bug，kind/enhancement，kind/question）。
• 应用一个priority/*标签：根据描述的影响，分配从 P0（关键）到 P3（低）的优先级。
• 可能会应用status/need-information：如果问题缺少关键细节（如日志或复现步骤），将被标记需要更多信息。
• 可能会应用status/need-retesting：如果问题引用的 CLI 版本距今超过六个版本，将被标记需要在当前版本上重新测试。

你应该做什么：

• 尽可能完整地填写问题模板。你提供的细节越多，分类的准确性就越高。
• 如果添加了status/need-information标签，请在评论中提供所请求的详细信息。

2. 当你提交一个拉取请求：Continuous Integration (CI)

此工作流程确保所有更改在合并之前符合我们的质量标准。

工作流程文件：.github/workflows/ci.yml 运行时机：每次向拉取请求推送时。 执行内容：

• 代码规范检查：检查你的代码是否符合我们项目的格式和风格规则。
• 测试：在 macOS、Windows 和 Linux 上，以及多个 Node.js 版本上运行我们的完整自动化测试套件。这是 CI 过程中最耗时的部分。
• 发布覆盖率评论：所有测试成功通过后，机器人将在你的 PR 上发布一条评论。该评论提供了你的更改测试覆盖情况的摘要。 你应该做什么：
• 确保所有 CI 检查通过。当一切成功时，你的提交旁边将出现一个绿色勾选标记✅。
• 如果检查失败（出现红色”X”❌），点击失败的检查旁边的”详情”链接查看日志，找出问题，并推送修复。

3. 持续审查拉取请求：PR Auditing and Label Sync

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

工作流程文件：.github/workflows/gemini-scheduled-pr-triage.yml 运行时机：对所有开放的拉取请求每15分钟运行一次。 功能：

• 检查关联的问题：机器人会扫描您的PR描述中是否有将其与问题关联的关键字（例如，Fixes #123，Closes #456）。
• 添加status/need-issue：如果没有找到关联的问题，机器人会在您的PR上添加status/need-issue标签。这是一个明确的信号，表明需要创建一个问题并与PR关联。
• 同步标签：如果已经关联了问题，机器人会确保PR的标签与问题的标签完全一致。它将添加任何缺失的标签，并移除任何不合适的标签，如果存在的话，还会移除status/need-issue标签。 您应该做什么：
• 始终将您的PR与一个问题关联。 这是至关重要的步骤。在您的PR描述中添加如Resolves #<issue-number>这样的行。
• 这将确保您的PR被正确分类，并顺利通过审查过程。

4. 问题的持续分类：Scheduled Issue Triage

这是一个后备工作流程，确保没有任何问题被分类过程遗漏。

• 工作流程文件：.github/workflows/gemini-scheduled-issue-triage.yml
• 运行时机：对所有开放的问题每小时运行一次。
• 功能：
  • 它会主动寻找那些完全没有标签或仍然带有status/need-triage标签的问题。
  • 然后它会触发与初始分类机器人相同的强大的基于Gemini的分析，以应用正确的标签。
• 您应该做什么：
  • 您通常不需要做任何事情。这个工作流程是一个安全网，确保每个问题最终都会被分类，即使初始分类失败。

5. 发布自动化

这个工作流程处理Gemini CLI新版本的打包和发布过程。

工作流程文件：.github/workflows/release-manual.yml 运行时机：每天的定时任务进行 “夜间” 发布，以及手动进行官方的补丁/小版本发布。 执行操作：

• 自动构建项目，提升版本号，并将包发布到 npm。
• 在 GitHub 上创建相应的发布版本，并附上生成的发布说明。 您应该做什么：
• 作为贡献者，您无需为此流程做任何事情。您可以确信一旦您的 PR 合并到 main 分支，您的更改将会包含在下一个夜间发布中。

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