我正在尝试建立一个自动化的CI流程GitHub和Jenkins。目标是让开发人员使用Jenkins Github Pull Request Merger创建功能分支并生成自动合并的拉取请求（如果他们通过构建）。 进一步的目标是要求拉取请求针对开放的GitHub问题。对我们来说，这意味着拉取请求标题或至少一个拉取请求提交消息必须包含类似“修复#NN”的子字符串，其中#NN必须引用打开的GitHub问题。这个'issue_opened'检查也是自动的 - 我们的'issue_opened'GitHub应用程序查询GitHub问题并检查提交消息和PR标题，然后它以状态发送拉取请求（出于测试目的，我总是发布'失败'） 。 设想的过程如下： 1.功能分支推送由Jenkins自动构建。 2.当功能分支准备就绪并通过Jenkins测试时，开发人员将生成拉取请求;这会自动触发步骤3和4，每个步骤独立运行： 3.我们的'issue_opened'GitHub应用程序非常快速地将状态发送到拉取请求。 4. Jenkins执行构建 - 它比第3步花费更长的时间。如果构建通过，Jenkins将应用该状态。如果所有状态都是“成功”，则拉取请求将自动合并。 我观察到的： 目前，我的pull请求正在将功能分支合并到master。主受保护（GitHub主分支：设置>分支>保护此分支>要求状态检查在合并之前传递，并且'issue_opened'状态检查设置为必需。）一切都按计划工作，除了Github Pull Request Merger中断GitHub惯例，只尊重自己的地位，而不是其他的地位。 因此PR合并仅取决于Jenkins： 在步骤3之后发布'失败'状态但在步骤4完成之前，GitHub报告“在合并之前必须通过所需状态”并指示'issue_opened'状态为'failure'。但是当Jenkins构建成功时，无论如何合并都会发生。 FWIW，如果功能分支在创建拉取请求时已经处于错误状态，也会发生合并。 我有什么方法可以做到我想做的事情？
在更加绝望的摆弄之后，我尝试启用GH主分支保护设置“设置”>“分支”>“受保护的分支”>“主”>“保护此分支”>“包括管理员”和“瞧”：它对我来说非常适合，或多或少： Jenkins Github Pull Request Merger仍尝试进行合并，但GitHub会返回： HTTP响应代码：405，消息：'Method Not Allowed'。 作为rc 405的结果，Jenkins生成了一个java.io.IOException，并从GH重新发出这条json消息： {“message”：“2中2个必需的状态检查未成功：1个失败，1个未决。”，“documentation_url”：“https://help.github.com/enterprise/2.10/user/articles/about-protected-branches”} 詹金斯然后发布了一个'失败'状态（由于构建本身没有失败，可能会因此而狡辩）。 这是有道理的，因为我是这个回购的管理员，但我没想到Jenkins Github Pull Request Merger不会检查状态。但我很高兴这将为我完成工作，但从我的观点来看，如果Jenkins首先发布构建状态，然后发布合并，那将更加清晰。更好的是，如果它检查了状态，它可以简单地跳过POST的尝试，我不必启用Include管理员保护。就目前而言，我没有办法在拉取请求中清除Jenkins发布的失败状态。因此，我们必须关闭此类失败的拉取请求并创建新的拉取请求。
自发布初始答案以来，我发现不能设置/启用来自Jenkins构建的GitHub Branch保护状态检查。如果未启用，则可以关闭失败的pull请求，更正导致其他状态检查或Jenkins构建失败的任何问题，然后通过打开新的pull请求再次启动pull请求过程。