来自 Fork 的评审请求
外部贡献者通过 Fork 发起评审请求时，平台默认会限制流水线运行：首次贡献者往往需要维护者批准之后才跑，而且这类运行默认拿不到仓库密钥。这是防滥用的设计，不是配置出错。理解这一点，才能正确判断外部贡献的流水线结果是否值得信任。
基本信息
| 平台默认行为 | 首次贡献者需维护者批准才运行工作流 |
|---|---|
| 密钥处理 | 这类事件默认不注入仓库密钥 |
| 高危做法 | 使用带目标分支上下文的事件时需格外谨慎 |
| 替代方案 | 高风险步骤改为审批后运行，或维护者本地复现 |
典型使用场景
- 判断外部贡献的流水线结果是否值得信任
- 为外部贡献者设计安全的自查方式
- 维护者本地复现外部改动之后再决定是否批准运行
- 审查工作流配置，确认没有把写权限与密钥暴露给不可信代码
- 处理供应链风险：外部贡献引入新依赖时额外核对
维护者操作
维护者操作
gh pr view 128 --json files,author # 查看改动文件与作者信息
git fetch origin pull/128/head:pr-128 # 把外部改动抓到本地分支
git log --oneline pr-128 # 查看该贡献的提交清单
git diff origin/main...pr-128 --stat # 概览改动范围，判断是否值得批准风险与对策
| 风险点 | 说明 | 对策 |
|---|---|---|
| 不可信代码执行 | 外部贡献的脚本在流水线中运行 | 限制密钥与写权限 |
| 带目标上下文的事件 | 以仓库身份执行，风险更高 | 严格限制可执行的内容 |
| 依赖引入 | 外部贡献可能带来第三方依赖 | 人工核对来源与版本 |
对外部贡献的流水线结果要保持警惕：同一份工作流在不同权限下行为可能不同，看到绿色并不代表与内部运行完全等价。
维护者可以先把改动抓到本地复现验证，再批准运行完整流水线，这样既给贡献者反馈，也把风险控制在可接受范围。