配置代码审查环境
选择独立 workflow 或复用云端 setup,并验证初始化与平台限制。
code review 在临时环境中执行 agentic 工作,可提前安装依赖或工具。共享初始化文件会同时影响 cloud agent;需要不同环境时,使用审查专用文件。
文件选择顺序
| 仓库文件 | 作用 |
|---|---|
.github/workflows/copilot-code-review.yml | 存在时用于 code review,优先于共享文件 |
.github/workflows/copilot-setup-steps.yml | 没有专用审查文件时复用 |
使用专用文件不意味着把 job 改名为 copilot-code-review;官方 runner 示例仍使用 copilot-setup-steps job。结构化 setup 的步骤说明见云端环境配置。
复用 setup 机制
通用 setup 文档要求唯一一个 copilot-setup-steps job,列出可调整的 steps、permissions、runs-on、services、snapshot、timeout-minutes,最大 timeout-minutes 为 59。其他 job 设置不应仅因为符合普通 Actions 语法就认为会被 Copilot 接受。
其中共享 copilot-setup-steps.yml 的触发要求是文件存在于默认分支;官方审查使用页明确专用文件优先,但没有在该段重新列出所有分支加载细节。因此不要把指令来自 head branch自动推广为 workflow 也一定来自 head。
安装依赖前先检出代码
如果步骤要读取锁文件并安装项目依赖,先 checkout,并给 setup 所需的 contents: read 权限。通用示例使用 actions/checkout@v6、actions/setup-node@v7 和 npm ci;实际项目应选匹配其工具链的步骤,不把示例 Node.js 20 当作审查统一要求。
通用 setup 机制不 checkout 时,代理会在步骤完成后自行检出。checkout 的 fetch-depth 可被系统覆盖,不应把自定义值当作保证的历史范围。
单独验证初始化
按已配置的 workflow_dispatch 或文件变更触发器运行测试,查看日志确认依赖确实安装。通用 setup 文档明确:步骤非零退出后跳过剩余步骤,代理仍可用当前环境开始工作;不能以最后存在审查输出反证 setup 全部成功。
code review 概览还说明 Actions 不可用或相关工作流失败时,仍可能给出没有额外 agentic 能力的审查。诊断时区分初始化结果、上下文收集与最终模型评论。
运行平台与网络独立选择
虽然通用环境页也介绍 Windows cloud agent,审查 runner 专题只确认 Ubuntu x64 Linux,且自托管仅 ARC。按审查 runner配置,不照搬其他代理平台。
网络策略位于 Internet access 的 code review 独立区域,与 cloud agent 分开,见审查防火墙。MCP 配置却由两个产品共用,二者范围不能混淆。