有能力"打破玻璃"并绕过Github分支保护来进行紧急修复吗?

5

我们的项目正在使用Github的分支保护来强制执行至少1个评审员对所有更改进行审查,管理员也不例外。

然而,有一天我们需要急于修复问题。这将需要快速合并分支,只有在有其他人可以审核时才能完成。但如果没有人在场怎么办?

我们需要绕过代码审查要求。

我们可以在合并时暂时禁用代码审查要求,但这并不理想,因为无法了解何时完成此操作,并且它只适用于管理员。

我希望有一种可审计的方法来完成这个任务。这通常称为“打破玻璃”即进行紧急合并和部署,因为出现了紧急情况,没有人可以审核你的代码。

是否有人找到了在Github受保护的分支上实现此目标的方法?

3个回答

2
我工作的地方使用一个叫做Github Organization Manager的程序来管理我们的分支保护,它基本上使用单个git存储库内的文件来管理我们存储库的设置。这允许在不给予管理员访问权限的情况下公开设置(组织者工具不允许用户执行诸如将存储库设为公共或删除存储库之类的操作)。还有其他类似的工具。
除了这样的东西,或者仅仅是给用户对存储库的管理员访问权限,Github 中没有内置的方法可以实现。如果您真的很担心这个问题,使用Github API构建一个“打破紧急玻璃”的仪表板或slackbot来移除分支保护甚至直接合并拉取请求也不会太困难。

不错,我想GHOM可以用来手动推送更改以禁用分支保护,然后允许合并,通过git历史记录进行审计,如果这样行得通,那听起来非常棒。谢谢! - Chris Adams
合并机器人用户也是一个有趣的想法 - 你知道有哪些我们可以从中开始,具有正确的API调用等的机器人吗? - Chris Adams
实际上,GitConsensus 应用程序可以。 - Robert Hafner

1
我们可以在合并时暂时关闭代码审查要求,但这并不理想,因为我们无法获知何时完成此操作,并且该解决方案仅适用于管理员。
实际上不仅适用于管理员。
自 2022 年 8 月起,您现在可以使用(仅限 GitHub 企业版):

使用新权限绕过分支保护

现在,您可以创建自定义角色来绕过分支保护,而无需授予管理员角色。

以前,要绕过分支保护,您必须是管理员,这提供了可能不需要的额外权限。

为了更严格地控制管理员权限,现在您可以创建一个具有“绕过分支保护”权限的自定义角色,只允许适当的访问。

Custom roles Inherited from Maintain role that adds the new Bypass branch protections permission -- https://i0.wp.com/user-images.githubusercontent.com/7575792/185173387-d982a441-eedc-4f28-96a3-cc49ba9484ca.png?ssl=1

要强制执行所有管理员和具有“绕过分支保护”权限的角色的分支保护,请在分支保护规则中启用不允许绕过上述设置

Checkbox selecting Do not allow bypassing the above settings -- https://i0.wp.com/user-images.githubusercontent.com/7575792/185174391-420680fd-dfa2-4821-b137-94dea3ba9037.png?ssl=1

此权限与将提交推送到受保护的分支权限不同,后者允许将提交推送到受保护的分支,但分支保护规则仍将适用,并可能导致提交被拒绝。

有关更多信息,请访问GitHub文档中的管理组织的自定义存储库角色


此功能仅适用于 GitHub 企业用户。 - Steve
@Steve 好观点。我已相应地编辑了答案。 - VonC

1
无论是手动还是使用工具/API,临时修改分支保护规则都需要小心,因为在此期间很容易解除所有打开的拉取请求(即您对main/master设置了一个分支保护规则,它适用于大多数或所有PR)。显然这取决于您的情况,但我曾经编写过一些工具来完成这项工作,当考虑到auto-merge features等因素以及人们可能会尽快点击合并按钮时,这可能会导致一些麻烦!最好是按PR进行处理。例如,如果您设置一个机器人来响应PR评论并留下批准审查?这需要一些操作,但您可能可以使用GitHub Actions(可以尝试类似这样的内容以开始对评论做出反应)。

有些人也使用PullApprove来达到这个目的,它在代码审查规则方面提供了更多的灵活性。一种方法是使用标签这里有一个在github.com/angular/angular上实践的例子)。在这种情况下看起来有点笨重,但你可以说这是当PullApprove未启用时,它应该实际上有一个通过状态:

# .pullapprove.yml
version: 3

pullapprove_conditions:
- condition: "'emergency' not in labels"
  unmet_status: success
  explanation: "Review disabled with the emergency label"

groups:
  ...

标签更改会直接显示在PR时间轴上(包括更改者),因此审计记录非常清晰:

PullApprove label change to bypass review requirements


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接