摘要

  • GitHub Actions 可在另一个流程被请求或完成时启动 workflow_run；GitHub 说明，下游流程可拥有上游流程没有的密钥和写入令牌。
  • 这种连接不是制品可信结论：结论条件、分支过滤、检出、制品选择与处理方式、以及实际权限，仍是彼此独立的决定。
  • 可复核的判断应把上游运行和修订、下游触发配置及已计算条件、精确制品和检出证据、权限上下文、下游决定和有时间边界的目标观察连接起来。

“发布流程在验证之后运行”可以是一个有用的架构描述，却不是完整的保管链。GitHub Actions 允许一个流程监听另一个流程的 workflow_run 事件，在后者被请求或完成时启动。GitHub 同时说明，即使前一流程不能访问，触发后的流程也可以取得密钥和写入令牌。这样的安排可能很审慎：权限较低的入口工作产出候选物，另一条受到更严格约束的流程再决定如何处置它。但这也明确划出了一条权限边界。上游运行的名称不能说明有什么跨越了这条边界。

首先必须把“完成”与“被接受”分开。GitHub 说明，workflow_run 所启动的运行并不会因前一流程的结论而自动停止；只有下游流程写入明确条件，例如 github.event.workflow_run.conclusion == 'success'，才会按该条件限制后续工作。因此，上游运行结束本身既不证明检查成功，也不证明下游作业计算过预期的成功条件。事件中出现的流程名，不是监听它的工作流文件修订，也不是下游收到的事件内容，更不是允许权限更高步骤继续执行的表达式。

分支过滤也有同样的边界。GitHub 规定，workflow_run 的分支过滤针对触发流程的分支，包含和排除模式还具有顺序。一条声明的 branches 规则可以说明政策意图；它不能证明某个制品来自预期提交，不能证明下游检出解析到了相同修订，也不能证明“发布分支已通过”这句口头结论准确对应了被计算的引用。如果该判断日后要经得起复核，上游运行标识、事件动作、头部分支与 SHA、流程身份和重跑上下文必须一并保存。

接着才是制品。GitHub 的事件文档示例显示，下游流程能够取得与触发运行相关的制品。这是一条访问路径，不是一张质量证书。某个制品即使与上游运行正确关联，仍可能不是后续操作应使用的逻辑输入。下游流程可以选取不同名称、下载一组对象而不是单一对象、在另一环境解包、使用另一个检出版本，或者把制品交给上游验证从未评估过的命令。重要记录不应只写“制品可用”，而应保存：上游运行身份，制品名称或标识，在可取得时的大小和摘要，获取时间，下游检出的 ref 与已解析 SHA，消费它的程序，以及其处理时的隔离或非执行条件。

GitHub 的安全使用参考解释了这种精确性为何必要。它警告说，若特权流程检出不可信的 pull request 内容，workflow_run 会变得危险；密钥、写入权限和共享缓存都可能放大下游流程所接受的内容。这一警告并没有指控某个仓库或某个制品。它指出的是结构问题：一句“上游流程通过了”既看不出下游特权流程接受了什么，也看不出它获准用该输入做什么。

触发器同样不是目标效果的回执。即使制品选对了，也可能只用于检查。下游命令可能被另一个权限边界拒绝，可能在调用目标前停止，可能作用于另一资源，或者虽已结束但之后的目标观察显示不同的运行状态。反过来，上游失败结论也可能仍在事件中传递，而下游条件阻止了一切特权操作。事件、条件、制品处理、命令决定和被观察的状态，是地图上的不同点。

实际可行的做法是一份受边界约束的下游回执。保存上游流程名称与运行标识、事件动作、头部分支和 SHA、结论、尝试或重跑信息，以及对其定义的稳定引用。保存下游流程定义的修订、workflow_run 选择器、分支过滤和允许或阻止关键作业的条件结果。保存检出声明及解析后的 SHA。对每个实际使用的制品，保存上游关联、名称或标识、可用摘要、获取上下文和处理路径。保存 GITHUB_TOKEN 实际权限、密钥可用性和相关缓存或环境边界的上下文，但不暴露敏感值。最后，把下游操作结果与单独计时的目标观察相连。敏感信息可以保护；从未记录的连接无法在事后补回。

这份记录刻意不宣称整个流水线“可信”。它只说明事件连了什么、下游流程决定了什么、消费了什么、掌握什么权限，以及观察到了什么。workflow_run 可以是一条有价值的控制边界，但它不应被要求为自己没有记录的制品、特权决定和运行效果背书。

来源

  1. GitHub Docs — Events that trigger workflows
  2. GitHub Docs — Secure use reference
  3. GitHub Docs — Triggering a workflow