如何允许自动CI流程使用Github分支保护来推送提交？

Question

Github不久前添加了分支保护，最近又添加了另一个要求复查的选项。

我尝试过要求进行审查和状态检查（管理员除外），并且喜欢工作流程。但这对我们的配置项/部署工具有负面影响。

例如，当我们发布一个新版本时，CI环境中有一个自动化过程，该过程会递增中的版本号package.json，提交该版本号并将其推送到存储库中。有一些这样的过程，例如清理任务。

这些自动化过程不需要检查或通过状态检查（到那时，状态检查已经作为部署管道的一部分运行了至少两次）。但是，启用分支保护后，CI“用户”将无法推送。

remote: error: GH006: Protected branch update failed for refs/heads/master. 
remote: error: Required status check "default" is expected. At least one approved review is required

以前，我们的配置项“用户”具有“写入”权限。我尝试将它尝试的仓库授予它“管理员”权限，但这显然是不够的。即使作为管理员，CI“用户”也无法推送。

在上面的图片中，我尝试删除了“评论”，希望状态检查能在没有进一步工作的情况下很好地进行。不！

我理想的情况是CI“用户”免于这些要求。看起来这不是一个功能。这可能意味着我唯一的选择是关闭大多数保护，包括我想要的一些保护。

但是我可能会对现有的CI管道进行某些更新或更改-或我可能创建的一些保护配置-最终结果是：

• 人类用户发现在合并或推送之前需要进行审查和状态检查。（校验）
• 只有维护者和配置项才能直接推送到分支机构。（校验）
• 管理员可以根据具体情况改写要求。（校验）
• CI可以直接推送到分支机构，而无需进行审查或等待状态检查。（需要帮忙）

任何人都做过类似的设置，或者知道如何避免CI“用户”被阻止？由于显然CI的“用户”无法实际导航至Github.com上的拉取请求，因此“使用管理员权限合并此拉取请求”旁边的复选框处于选中状态。是否有CLI标志--usemyadminprivilegestopushthis？

Answer 1

我实际上并没有弄清楚为什么我会失败；我后来无法使用相同的配置重现该问题。

第二天，什么是我所描述的。

1. 保护分支

2. 但不要包括管理员进行评论/状态检查

3. 确保您的 CI“用户”是管理员

这样做的好处是 Github UI 仍然鼓励管理员等待状态检查和审查。在拉取请求工作流中很有用。然而，CLI 的使用对管理员来说不受影响，除了无法强制推送或删除 - 期望的结果。

如果有人有只需要写入而不是管理员访问权限的设置提示，或者有关如何跨多个请求跟踪状态/审查检查成功的信息，请分享它们。

（我相信在我的情况下，CI 配置指向错误的存储库。它在第二天开始工作，有人提到重置配置，但不幸的是，我无法确认这适用于我们日志中的信息中的每一个故障.)