GitHubActions 中的 pull_request 和 pull_request_target 事件有什么区别

Question

GitHubActions

中的

pull_request

和pull_request_target事件有什么区别？

我在 GitHubActions Docs 中找到了这个解释：

此事件（pull_request_target）在基础的上下文中运行 拉取请求，而不是在合并提交的上下文中，如 pull_request 事件确实如此。

但是，我无法理解 githubAction 中的上下文是什么。有谁能解释一下吗？

Answer 1

这在 Nathan Davison 的“Github 操作和恶意拉取请求的威胁”中进行了总结：

当 Github 于 2018 年首次推出 Actions 时，情况并非如此（或者至少，并非有意如此）——在 Actions 术语中，

pull_request

事件及其变体是唯一触发的事件。 PR 从分叉中打开，这些事件无法访问存储库机密，包括访问只读的

GITHUB_TOKEN

值。

但是，过了一段时间，即 2020 年 8 月，添加了

pull_request_target

活动。

此事件被赋予存储库机密和完整的读/写

GITHUB_TOKEN

来启动，但是有一个问题 - 此操作仅在拉取请求的target分支中运行，而不是在拉取请求的分支本身中运行。

这与 CircleCI 方法不同，当它被指示与分叉存储库中的 PR 共享秘密时，它会愉快地检查拉取请求的代码，包括拉取请求中的管道配置（这将允许提交拉取请求只是为了窃取令牌）以及存储在 CircleCI 项目设置中的秘密）。

博客文章证实：

为了保护恶意用户的公共存储库，我们使用只读令牌运行从存储库分叉引发的所有拉取请求工作流程，并且无法访问机密。
这使得诸如标记或评论拉取请求之类的常见工作流程变得非常困难。

为了解决这个问题，我们添加了一个新的

pull_request_target

事件，其行为方式与具有相同过滤器和有效负载的

pull_request

事件几乎相同。

但是，该事件不是针对来自合并提交的工作流和代码运行，而是针对来自拉取请求的工作流和代码运行。

这意味着工作流程是从受信任的源运行的，并且有权访问读/写令牌以及机密，使维护者能够安全地评论或标记拉取请求。
此事件也可以与私有存储库设置结合使用。

Answer 2

我的理解是：

鉴于 Alice 有一个存储库

foo

(alice/foo) 并且 Bob 从 Alice (bob/foo) 分叉了

foo

。

现在 Bob 向 Alice 发送一个 Pull 请求到 foo 以进行增强。

如果您使用

on: pull_request

，则工作流程将运行由

bob/foo

定义的代码，但也可以访问

alice/foo

。

换句话说，Bob 使用 Alice 的资源来运行他的工作流程代码，这是绝对不行的，因为这意味着他可以使用自己的恶意工作流程定义窃取 Alice 的凭证。

但是如果您使用

on: pull_request_target

，那么工作流在仅存在于

alice/foo

上的代码上运行，因此 Bob 无法破解 Alice，因为 Alice 有足够的能力不让任何恶意工作流代码通过代码审查。

但是，如果 Bob 是合法的，这也给他增加了额外的负担，因为他确实想使用 Alice 工作流程上的官方设置来测试他的代码，比如从 Bob 的 Alice 的 Maven/Nuget 包存储库中获取特殊的依赖项来构建他的工件无权访问（因此他无法在本地测试），或者 Bob 希望在 Alice 的存储库上发布一个开发 Docker 镜像，假设某些基础镜像只能从 Alice 和

alice/foo

访问。 （同样，这种情况一开始可能听起来很愚蠢和新颖，但实际上在具有私有依赖项的大型项目中非常常见）

所以，大多数人只是使用折衷方案，仍然使用

on: pull_request

，但不是让你立即运行，而是贡献者需要先进行多次代码审查和最低数量的 LGTM。