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

Question

GitHubActionspull_request和pull_request_targetevent之间有什么区别？

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

此事件 (pull_request_target) 在拉取请求基础的上下文中运行，而不是像 pull_request 事件那样在合并提交的上下文中运行。

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

Answer 1

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

\n

\n

当 Github 在 2018 年首次推出 Actions 时，情况并非如此（或者至少不是有意如此）——在 Actions 术语中，该pull_request事件及其变体是从某个 PR 打开时触发的唯一事件。分叉，并且这些事件是为了无法访问回购秘密，包括访问GITHUB_TOKEN只读值。

\n

然而，过了一段时间，即 2020 年 8 月，该pull_request_target活动被添加。

\n

此事件被给予存储库机密和完整的读/写GITHUB_TOKEN启动，但是有一个问题 - 此操作仅在拉取请求的目标中运行分支中运行，而不是在拉取请求的分支本身中运行。

\n

这与 CircleCI 方法不同，后者在被指示与分叉存储库中的 PR 共享机密时愉快地检查了拉取请求的代码，包括拉取请求中的管道配置（这将允许将拉取请求提交到窃取 CircleCI 项目设置中存储的代币和秘密）。

\n

\n

博客文章证实：

\n

\n

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

\n

为了解决这个问题，我们\xe2\x80\x99添加了一个新pull_request_target事件，其行为方式与pull_request具有相同过滤器和负载集的事件几乎相同。

\n

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

\n

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

\n

\n