Jenkins Github拉请求合并不尊重状态

Question

我正试图建立一个自动化的CI过程GitHub和Jenkins。目标是让开发人员创建特性分支，并生成使用Jenkins Github pull Request合并自动合并的pull请求（当然，如果它们通过了构建）。

另一个目标是要求pull请求针对开放的Github问题。对我们来说，这意味着pull request标题或至少一条pull request提交消息必须包含类似“fixes#nn”的子字符串，其中#nn必须引用openGitHub问题。这个“issue_opened”检查也是自动的--我们的“issue_opened”GitHub应用程序查询GitHub问题并检查提交消息和PR标题，然后发布带有状态的请求（出于测试目的，我总是发布“failure”）。

设想的过程如下:
1。特性分支推送由Jenkins自动构建。
2。当一个特性分支准备好并通过Jenkins测试时，开发人员将生成一个拉请求；这将自动触发步骤3和4，每个步骤都独立运行:
3。我们的'issue_opened'GitHub应用程序很快就会向请求发布一个状态。
4。Jenkins执行构建--它需要比步骤3长得多的时间。如果构建通过，Jenkins将应用该状态。如果所有状态都是'success'，则拉请求将自动合并。

我观察到的情况:
当前，我的拉请求正在将特性分支合并到master。主分支受到保护（GitHub主分支:设置>分支>保护此分支>要求在合并前通过状态检查，并且“issue_opened”状态检查设置为required。）除了Github拉请求合并打破了Github约定，只尊重自己的状态，而不尊重其他状态之外，一切都按计划进行。
所以PR合并只依赖于Jenkins:
在第3步发布“失败”状态后，但在第4步完成之前，Github报告“合并前必需的状态必须通过”，并指示“issue_opened”状态为“失败”。但是当Jenkins构建成功时，无论如何都会发生合并。
FWIW，如果在创建请求时功能分支已经处于不良状态，那么合并也会发生。
我有什么方法可以让它做我想做的事情吗？

Answer 1

在经历了更多绝望的调整后，我尝试启用GH主分支保护设置设置>分支>受保护的分支>master>protect this branch>include administrators和'voila':它对我来说非常有效，或多或少:Jenkins Github请求合并仍然试图进行合并，但Github返回以下内容:
HTTP响应代码:405，消息:'method Not alloving'。作为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随后发布一个“failure”状态（人们可能会对此提出质疑，因为构建本身没有失败）。
这是有道理的，因为我是这个回购的管理员，但我没有预料到Jenkins Github Pull Request合并不会检查状态。但我很高兴这将为我完成工作，尽管从我的角度来看，如果Jenkins首先发布构建状态，然后发布合并，会更干净。更好的是，如果它检查了状态，它可以简单地跳过发送尝试，我就不必启用include administrators保护。目前，我看不到清除Jenkins发布的pull请求失败状态的html" target="_blank">方法。因此，我们必须关闭此类失败的请求并创建新请求。

自从发布初始答案以来，我发现不能设置/启用来自Jenkins构建的GitHub分支保护状态检查。如果未启用，则可以关闭失败的pull请求，纠正导致其他状态检查或Jenkins构建失败的任何问题，然后通过打开新的pull请求重新启动pull请求过程。