【问题标题】:Automatically merge verified and tested GitHub Pull Requests自动合并经过验证和测试的 GitHub 拉取请求
【发布时间】:2017-03-16 10:31:02
【问题描述】:

我想自动(即来自 Jenkins)合并已被某人批准并已成功测试的 GitHub 拉取请求;换句话说,当所有三个复选标记都是绿色时:

这可能吗?我没有找到任何关于 GitHub 新的“已批准更改”代码审查功能的 API 文档。

【问题讨论】:

  • 感谢@kfb 的回答,我写了一个NodeJS script 来做到这一点:听GitHub 并在准备好时自动合并。
  • 现在(2021 年 2 月)正式可用:见 my answer below

标签: github github-api


【解决方案1】:

有一个新的PullRequestReviewEvent webhook 在以非待定状态提交评论时触发。 Webhook 的主体包含 ["review"]["state"] 字段,当所有审阅者都批准更改时(即当您在 UI 中获得绿色的“更改已批准”勾号时),该字段将为 approved

将此与拉取请求的头部 SHA 的 StatusEvent 结合起来,以从 CI 等处获取状态检查,然后最后通过 requesting the pull request from the API 来检查拉取的“合并能力”:

GET /repos/:owner/:repo/pulls/:number

一旦你拥有了这三样东西,你就可以merge the pull request 使用:

PUT /repos/:owner/:repo/pulls/:number/merge

和适当的有效载荷参数。请注意,您需要 Accept: application/vnd.github.polaris-preview+json 来获取某些有效负载参数,因为它们处于预览阶段。

【讨论】:

  • 这可以通过简单的 API 调用来实现吗?我想创建一个 cli 程序,它接受像 repo-name ,pr-id 这样的参数,它可以检查 PR 的状态并根据来自 api 响应的状态合并它,而不是依赖于基于事件的钩子
  • 你可以使用Issue Timeline API阅读事件,虽然我自己没有使用过这个API,所以不能就如何实现你所追求的提供任何具体建议。
  • 我设置了一个 nodejs 服务器来监听基于钩子的事件,但即使其中一位审阅者选择了 CHANGES_REQUESTED ,我也获得了批准状态。任何线索为什么?
  • 不知道,对不起!
【解决方案2】:

官方文档:“Managing auto-merge for pull requests in your repository”。


现在(2020 年 12 月,4 年后)可用:

Pull request auto-merge public beta

拉取请求自动合并现已作为公开测试版推出!

使用自动合并,当满足所有合并要求时,拉取请求可以自动合并。无需再等待漫长的检查完成,您就可以按下合并按钮!

要使用自动合并,存储库维护者或管理员必须首先启用存储库设置以允许自动合并 (see steps)。
然后任何具有写入权限的用户都可以通过导航到拉取请求页面来启用或禁用自动合并。

请记住,自动合并仅适用于针对具有所需审查或所需状态检查的分支的拉取请求,因此仅适用于 Team 和 GitHub Enterprise Cloud 计划的公共仓库和私有仓库。

详细了解pull request auto-merge


2021 年 2 月更新:

Pull request auto-merge is now generally available

通过自动合并,可以将拉取请求设置为在满足所有合并要求时自动合并。
无需再等待缓慢的 CI 作业或测试完成,只需单击合并按钮即可!

要使用自动合并,首先在存储库设置中有管理员allow auto-merge

然后要启用自动合并,请导航到 GitHub.com 或 GitHub Mobile 上的拉取请求,然后点击按钮启用。

请注意,只有具有合并权限的用户才能启用自动合并,并且当合并要求不满足时,例如缺少批准或未通过所需的状态检查。

GraphQL API 将于本周晚些时候推出。 pull request webhook event 现在还包括指示何时启用或禁用自动合并的操作。

了解更多关于pull request auto-merge


但是,正如The Godfatherthe comments 中提到的那样:

问题在于它不能自动更新。

所以一旦你的 repo 有“branches must be up-to-date”并且其他一些 PR 被合并,这个“auto-merge”就不再起作用了。

应该和Gitlab一样叫法:“merge when pipeline succeeds”,至少不会那么混乱……——


2021 年 8 月更新:

维护者现在可以管理存储库中自动合并的可用性

维护者现在可以管理存储库级别的“允许自动合并”设置。
此设置在默认情况下处于关闭状态,用于控制自动合并是否可用于存储库中的拉取请求。
以前,只有管理员才能管理此设置。

此外,现在可以使用“Create a repository”和“Update a repository”REST API 控制此设置。

【讨论】:

  • @dgmltn 这应该被选为正确答案。
  • OP 要求“当所有三个复选标记均为绿色时”。当仅通过所需的检查并且其他检查仍在运行时,Github 的功能合并,此时检查仍为黄色。我在my answer 中编写和介绍的应用程序可以满足 OP 的要求。 ?
  • @AdamMillerchip 同意了,当你去年提出这个答案时,我赞成你的答案。
  • 这个问题是它不做自动更新。因此,一旦您的回购有“分支必须是最新的”并且其他一些 PR 被合并,这个“自动合并”就不再起作用了。应该和 Gitlab 一样的叫法:“管道成功时合并”,至少不会那么混乱……
  • @TheGodfather 好点。感谢您的反馈。我已将您的评论包含在答案中以提高知名度。
【解决方案3】:

我写了一个应用程序来做到这一点。它响应审查、标记和提交状态/检查事件,并在合并按钮为绿色时合并。

合并按钮为绿色时合并意味着您可以在GitHub设置中配置可合并PR的要求,无需为应用编写单独的配置。

Mergery 是:

  • 免费,包括私有存储库。
  • 快。它是事件驱动的,不会按计划运行。
  • 简单。无需配置。只需将您的 PR 标记为 automerge

【讨论】:

    【解决方案4】:

    您可以使用Mergify 来执行此操作,因为它就是为此而创建的。只需在您的存储库中设置一个最小的.mergify.yml 文件:

    rules:
      default:
        protection:
          required_status_checks:
            context:
              - continuous-integration/travis/pr
          required_pull_request_reviews:
            required_approving_review_count: 1
    

    你会很高兴的。

    (免责声明:我是 Mergify 的创始人之一)

    【讨论】:

      【解决方案5】:

      使用作为新方法之一的 github 操作,可以做到这一点。我写了一个blog,关于使用 github 操作自动批准和自动合并 PR。但是,如果目的只是合并 PR,那么此工作流程中的第二个工作就足够了。

      【讨论】:

        【解决方案6】:

        https://github.com/bobvanderlinden/probot-auto-merge 是一个免费的 GitHub 应用程序,可以完成这项工作。可在.github/auto-merge.yml 中配置。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2015-05-14
          • 2022-08-14
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2016-12-11
          相关资源
          最近更新 更多