使用 GitHub Actions 检测到 master 的直接推送答案

【问题标题】：Detect direct pushes to master w/GitHub Actions使用 GitHub Actions 检测到 master 的直接推送
【发布时间】：2021-02-27 06:06:55
【问题描述】：

我们目前有一个 GitHub 存储库，其中我们的 master 分支受到保护，除了管理员之外的所有人，他们能够直接提交并推送到分支，而无需先打开拉取请求。我们正在寻找一种在管理员直接提交到master 时发送 Slack 通知的方法，以引起人们对分支保护被覆盖这一事实的关注。这可能是由于极端情况而故意发生的，或者在最坏的情况下是错误的（需要解决）。

这似乎可以通过 GitHub Slack action、作业/步骤定义上的 if 键以及来自 push 事件 JSON 的一些信息的组合来实现。

最后一部分是我卡住的地方：我没有看到一种明显的方法来使用 push 事件中包含的数据来区分违反我们的分支保护政策的一次性提交和正常/合规的拉取请求。

有人对这是否可能有任何想法吗？也许我应该将这个工作流附加到另一个事件，这会给我提供区分差异并启动 Slack 通知所需的信息？

【问题讨论】：

你可以使用这个请求来查看提交是否有任何关联的拉取请求：docs.github.com/en/rest/reference/…，你也可以检查谁是提交的作者，我认为这是足够的信息来区分提交，你怎么看？
@soltex 我认为您可以将其发布为答案。将推送的提交与任何合并 PR 的提交交叉引用似乎是解决此问题的唯一方法。

标签： github slack github-actions

【解决方案1】：

一般来说，使用 GitHub Actions 来做这种通知是有问题的，因为用户可以简单地删除或中和报告这种情况的代码，然后推送到主分支。所使用的 Actions 工作流程将是作为该提交的一部分推入 repo 的工作流程，因此这不是有效的控制。

您可能希望改为使用 webhook 来通知服务这一事实，然后查看 HEAD 提交，解析提交消息以提取 PR 编号，并验证提交的第二个父项是与PR的负责人相同。请注意，如果您使用 squash 合并，这将不起作用，因为没有简单的方法来验证由 squash 合并创建的提交是否与创建它的分支创建的提交相同。

【讨论】：

我认为这+@soltex的建议是解决我提出的问题的好方法。实际上，我们通过简化事情来满足我们的要求，只需将所有推送到master 记录到 Slack 中，这会通知我们 PR 进入和直接提交。