为代码覆盖率使用自动设置时，AI 驱动的代理会分析存储库、标识测试框架，并打开一个拉取请求，其中包含一个可供评审的覆盖工作流。
使用此功能无需额外付费。
代理的工作原理
代理在三个阶段中工作：
- 发现： 代理读取 CI 配置、文档和生成文件，以了解项目结构并识别测试框架。
- 执行： 代理会安装依赖项，生成项目，并运行启用了覆盖范围的测试。 如果尚未配置覆盖率工具，代理会将其添加到项目配置（例如，
vitest.config.ts或jest.config.js）。 - 工作流集成： 如果代理生成有效的覆盖报告，它会检查存储库是否已具有针对 GitHub Actions 拉取请求运行测试的工作流。 如果是这样，代理会通过覆盖上传步骤扩充该工作流。 如果没有，它将创建新的工作流文件并打开拉取请求。
代理停止时
在以下情况下，代理可能会在打开拉取请求之前停止：
- 未找到测试。 代理找不到要检测的测试，因此没有可为其生成覆盖范围。
- 无法重现生成。 缺少专用注册表、专有 SDK 或系统依赖项，阻止代理验证测试套件。
如果代理停止或产生意外结果，可以查看代理的会话日志以了解详细信息。 导航到存储库中的“ 任务 ”选项卡，查找与工作流生成尝试关联的会话。
- 不支持的覆盖率报告转换。 代理不会从仅公开聚合计数器的报表中重新构造 Cobertura XML。 例如，JaCoCo XML 不包含足够的行和分支结构来上传可信 Cobertura，因此仅生成 JaCoCo XML 的 JVM 项目可能需要手动设置。
拉取请求结果
注意
代理会立即打开拉取请求，其中包含不包含代码更改的初始规划提交。 实际实现提交通常在几分钟后到达。 如果拉取请求最初显示 0 个已更改的文件，请等待几分钟并刷新页面。
如果代理成功打开拉取请求，则拉取请求可能处于以下状态之一：
- 可合并 as-is： 工作流在 CI 中成功完成，并正确上传覆盖率。
- 准备循环访问： 工作流运行但需要调整（例如缺少机密、自承载运行程序配置或本地验证与 CI 之间的路径差异）。
- 用作参考： 维护人员可能倾向于自行配置覆盖范围，使用代理的拉取请求作为它发现的生成和测试命令的起点。