GitHub 在拉取请求后调用 CI 构建

Question

背景

我们正在 GitHub 上创建拉取请求。在 PR 获得批准并且更改在 CircleCI 上成功编译和测试后，我们按下按钮Merge pull request。

按下按钮后，我们希望 GitHub 立即合并 PR，但它首先再次在 CircleCI 上运行完全相同的构建，然后完成合并。

题

如何在不再次运行 CI 构建的情况下直接按下Merge pull request后合并成功的 PR ？

如果不可能，那么有没有办法减少一些开销？

对于不成功的 PR，我们希望阻止合并...

Answer 1

这不是正在发生的事情。当您将一个分支合并到 GitHub 上的默认分支（比如 master）时，GitHub 会按预期执行，合并代码。然后默认分支将有一个或多个新提交（取决于您在 GitHub 中选择的合并类型）。

因为 CircleCI 检测到具有新提交的分支，然后它会为该分支运行构建。这不是由 GitHub 发起的，而是 CircleCI 像往常一样工作。新提交意味着新构建。

正如 JB Nizet 评论的那样，这通常是必要的，因为特性分支的尖端并不总是使用 master 上的最新代码进行测试。例如，您的 CircleCI 配置可以具有仅在master.

就我个人而言，我不会试图阻止最后一个版本的运行。这是一项安全检查，这正是 CI 的首要目的。如果你真的想要，当你第一次点击合并按钮时，GitHub 会给你最后一次修改合并提交的提交消息和正文的机会。您可以添加[skip ci]到该提交消息的末尾，CircleCI 将忽略提交并且不运行构建。