GitHub Actions重跑一次，提交与权限主体为什么仍来自原触发

工作流重跑以后，开发者看到分支已经有了新提交，便以为本次一定验证了最新代码。GitHub Actions的官方说明给出不同语义：重跑延续的是原来那次触发事件的上下文，不能只凭重跑时间更晚，就把它等同于一次新的分支触发。

文档明确指出，重新运行仍使用原始事件的GITHUB_SHA与GITHUB_REF。前者表示提交SHA，后者表示Git引用。这意味着记录一次重跑时，需要能追溯原事件，而不能用此刻分支页面显示的位置替换旧记录中的提交身份。

权限主体也有类似的区分。原文说明，重跑采用最初触发工作流的actor所具有的权限，而不是发起重跑者的权限。这里谈的是这项机制如何选择主体，不是对某个账户的实际权限作审计。本文没有查看组织成员、令牌或私有仓库配置。

一个自拟的交接情境是：同事乙重新运行同事甲先前触发的工作流。资料中若只记“乙今天运行”，就会掩盖原触发者与重跑发起者不同这一事实。较清楚的记录可以分别保留原运行、尝试次数、原提交与重跑发起记录，便于后续解释这次结果对应什么。

保留相同SHA和ref，也不等于所有输入与产物必然相同。官方此处说明的是事件上下文；本文没有据此核验依赖、缓存、外部服务或构建环境。若两次结果不同，仍需真实日志与输入证据，而不能仅凭提交一致就排除所有环境差异。

同理，某次重跑通过，不应被改写成当前分支最新提交已经通过，更不能转成部署或业务数据已经恢复。它首先是一条与原运行相关的结果，需要按实际任务范围说明。本文没有触发工作流，也未执行构建、发布或回滚。

这份官方文档还包含重跑入口和操作步骤，本稿只采用上下文与主体语义，不提供执行命令。对持续集成交付记录而言，原触发者、重跑发起者与目标提交各有含义；把三者写清，比只记录一个新的运行时间更能说明结果的归属。