GitHub Actions中pull_request与pull_request_target事件的区别及context解析

一、先搞懂这里的“context”指什么 #

在GitHub Actions的语境里，这里的**context（上下文）**核心包含两层关键内容：

• 代码环境：Workflow运行时拉取的代码版本、代码所属的分支/仓库归属
• 执行权限：Workflow运行时使用的GITHUB_TOKEN拥有的权限范围，以及能访问的仓库资源（比如是否能推送代码、修改标签、读写仓库配置等）

二、pull_request与pull_request_target的核心区别 #

1. 运行的代码环境不同 #

• pull_request事件：自动拉取PR的模拟合并提交版本（即PR分支代码和基准分支代码合并后的代码）来运行Workflow，全程基于PR提交的代码。
• pull_request_target事件：拉取PR的基准分支（比如main/master）的代码来运行Workflow，用的是仓库主分支的代码，和PR提交的代码无关。

2. 执行权限差异 #

• pull_request事件：如果是外部fork仓库提交的PR，Workflow的权限会被严格限制，GITHUB_TOKEN只能访问临时生成的合并提交仓库，无法读写原仓库的核心资源，这是GitHub的安全防护机制，防止恶意PR执行危险操作。
• pull_request_target事件：无论PR来自哪里，都在原仓库基准分支的上下文运行，GITHUB_TOKEN拥有原仓库的默认完整权限，可直接操作原仓库的各类资源。

3. 安全风险不同 #

• pull_request：权限受限且基于PR代码运行，安全风险低，但无法完成需要原仓库权限的操作（比如自动合并PR、推送测试报告到原仓库等）。
• pull_request_target：基于基准分支代码运行，权限完整，但如果Workflow中存在执行PR代码的逻辑，可能被恶意PR利用引入风险，使用时需严格校验PR来源或限制代码执行范围。

4. 适用场景不同 #

• pull_request：适合PR的代码检查、单元测试、lint校验等无需原仓库权限的常规操作，所有PR都能安全运行。
• pull_request_target：适合需要原仓库权限的操作，比如自动给PR添加标签、推送测试产物到原仓库、自动合并符合条件的PR等，建议仅在信任的PR来源下使用。

内容的提问来源于stack exchange，提问作者김대영