合并请求审批规则

  • Tier: 专业版,旗舰版
  • Offering: JihuLab.com,私有化部署

审批规则定义了一个合并请求在合并之前必须接收到多少次审批,以及哪些用户应该进行审批。可以与代码所有者一起使用,以确保更改被维护该功能的群组以及负责特定监督领域的任何群组审查。

可以定义审批规则:

  1. 作为项目默认值
  2. 每个合并请求

可以配置审批规则:

  1. 适用于整个实例

如果没有定义默认审批规则,任何用户都可以批准合并请求。即使没有定义规则,也可以在项目设置中强制执行所需审批者的最小数量

目标不同项目的合并请求,例如从一个分叉到上游项目,使用目标(上游)项目的默认审批规则,而不是源(分叉)。

合并请求审批可以全局配置,以适用于所有(或子集)项目,通过策略合并请求审批策略还提供了更多细粒度配置选项的灵活性。

添加审批规则#

History
    • 针对所有受保护分支的审批规则在极狐GitLab 15.3 中引入。

先决条件:

  • 必须至少拥有项目的维护者角色。
  • 要在 JihuLab.com 中将群组添加为审批者,必须是该群组的成员或该群组必须是公开的。

要添加合并请求审批规则:

  1. 在左侧边栏中,选择 搜索或转到 并找到你的项目。
  2. 选择 设置 > 合并请求
  3. 合并请求审批 部分,在 审批规则 部分,选择 添加审批规则
  4. 在右侧边栏,完成字段:
    • 需要的审批数量 中,值为 0规则为可选,大于 0 的任何数字则创建一个必要的规则。 所需的审批最大数量为 100
    • 添加审批者 中,选择 有资格批准的用户或群组。 极狐GitLab 根据合并请求更改文件的先前作者建议审批者。
  5. 选择 保存更改。可以添加多个审批规则

审批规则覆盖的配置决定了新规则是否适用于现有合并请求:

  • 如果允许审批规则覆盖,则这些默认规则的更改不适用于现有合并请求,除了规则的目标分支的更改。
  • 如果不允许审批规则覆盖,则所有默认规则的更改都适用于现有合并请求。任何在允许审批规则覆盖期间手动覆盖的审批规则都不会被修改。

编辑审批规则#

先决条件:

  • 必须至少拥有项目的维护者角色。
  • 要在 JihuLab.com 中将群组添加为审批者,必须是该群组的成员或该群组必须是公开的。

要编辑合并请求审批规则:

  1. 在左侧边栏中,选择 搜索或转到 并找到你的项目。
  2. 选择 设置 > 合并请求
  3. 合并请求审批 部分,在 审批规则 部分,找到要编辑的规则旁边的 编辑
  4. 在右侧边栏,编辑字段:
    • 需要的审批数量 中,值为 0规则为可选,大于 0 的任何数字则创建一个必要的规则。 所需的审批最大数量为 100
    • 要移除用户或群组,请识别要移除的群组或用户,并选择 移除 ()。
  5. 选择 保存更改

删除审批规则#

先决条件:

  • 必须至少拥有项目的维护者角色。

要删除合并请求审批规则:

  1. 在左侧边栏中,选择 搜索或转到 并找到你的项目。
  2. 选择 设置 > 合并请求
  3. 合并请求审批 部分,找到要删除的规则旁边的垃圾桶 ()。
  4. 选择 移除审批者

多个审批规则#

要在合并请求上强制执行多个审批规则,请为项目添加多个默认审批规则。

当一个合格审批者批准合并请求时,它会减少审批者所属的所有规则的剩余审批次数(审批 列):

Merge request approvals widget

合格审批者#

要成为项目的合格审批者,用户必须至少是以下之一的成员:

如果以下任一项为真,具有开发者角色的用户可以批准合并请求:

  • 在项目或合并请求级别添加为审批者的用户。
  • 合并请求中更改的文件的代码所有者用户。

只有当以下两项都为真时,具有报告者角色的用户才能批准:

  • 用户是已与项目共享的群组的一部分。 该群组必须至少具有报告者角色。
  • 该群组已被添加为合并请求审批者。

有关详细说明,请参见合并请求审批职责分离

为了显示谁参与了合并请求审查,合并请求中的审批小部件显示一个 评论者 列。此列列出了在合并请求中发表评论的合格审批者。它帮助作者和审查者确定与谁联系以询问合并请求内容的问题。

如果所需的审批数量大于指定的审批者数量,项目中至少具有开发者角色的其他用户的审批会计入满足所需的审批数量,即使这些用户未在审批规则中明确列出。

群组审批者#

可以将一组用户添加为审批者。该群组的所有直接成员都可以批准规则。继承成员不能批准规则。

通常,该群组是顶级命名空间中的子群组,除非与外部群组合作。如果与另一个群组合作,必须在将群组指定为群组审批者之前共享项目访问

用户在审批者群组中的成员身份决定了其个人审批权限:

  • 继承成员不被视为审批者。只有直接成员才能批准合并请求。
  • 一个来自群组审批者群组的用户稍后 被添加为个人审批者时,算作一个审批者,而不是两个。
  • 合并请求作者默认情况下不算作其自身合并请求的合格审批者。要更改此行为,请禁用 防止作者批准 项目设置。
  • 合并请求的提交者可以批准合并请求。要更改此行为,请启用 防止提交者批准 项目设置。

代码所有者作为合格审批者#

如果在存储库中添加了代码所有者,文件的所有者成为项目中的合格审批者。要启用此合并请求审批规则:

  1. 在左侧边栏中,选择 搜索或转到 并找到你的项目。
  2. 选择 设置 > 合并请求
  3. 合并请求审批 部分,在 审批规则 部分,找到 所有合格用户 规则。
  4. 需要的审批数量 列中,输入所需的审批数量。

也可以要求代码所有者审批用于受保护的分支。

启用报告者角色用户的审批权限#

在具有报告者角色的用户可以合并到受保护分支之前,可能需要授予他们批准合并请求的权限。某些用户(如管理者)可能不需要推送或合并代码的权限,但仍然需要对建议的工作进行监督。

先决条件:

  • 必须选择特定分支,因为此方法不适用于 All BranchesAll protected branches 设置。
  • 共享群组必须添加到审批规则中,而不是单个用户,即使添加的用户是该群组的一部分。

要在不授予这些用户推送访问权限的情况下启用审批权限:

  1. 创建受保护分支
  2. 创建新群组
  3. 将用户添加到群组,并为用户选择报告者角色。分配更高的角色可能会导致意外行为。
  4. 与群组共享项目, 至少具有报告者角色。
  5. 在左侧边栏中,选择 搜索或转到 并找到你的项目。
  6. 选择 设置 > 合并请求
  7. 合并请求审批 部分,在 审批规则 部分:
    • 对于新规则,选择 添加审批规则 并以受保护分支为目标。
    • 对于现有规则,选择 编辑 并以受保护分支为目标。
  8. 在右侧边栏,在 添加审批者 中,选择你创建的群组。
  9. 选择 保存更改

编辑或覆盖合并请求审批规则#

可以通过以下方式覆盖项目的合并请求审批规则:

  • 编辑现有合并请求。
  • 创建新合并请求。

先决条件:

  • 必须拥有管理员访问权限,或者以下所有条件必须为真:
    • 必须至少具有开发者角色,或者项目必须接受来自外部成员的贡献。
    • 必须是合并请求的作者。
    • 项目设置防止编辑审批规则被禁用。

要覆盖合并请求的审批者:

  1. 创建新合并请求时,滚动到 审批规则 部分, 并在选择 创建合并请求 之前添加或移除所需的审批规则。
  2. 查看现有合并请求时:
    1. 在左侧边栏中,选择 搜索或转到 并找到你的项目。
    2. 选择 代码 > 合并请求 并找到你的合并请求。
    3. 选择 编辑
    4. 滚动到 审批规则 部分。
    5. 添加或移除所需的审批规则。
    6. 选择 保存更改

管理员可以更改合并请求审批设置 以防止用户覆盖合并请求的审批规则。

需要多个审批的规则#

要创建需要多个审批的审批规则:

  • 创建编辑规则时,将 需要的审批数量 设置为 2 或更多。

要为规则要求多个审批,也可以使用 APIapprovals_required 属性设置为 2 或更多。

配置可选审批规则#

对于希望审批但不是必须的项目,可以选择合并请求审批。要使审批规则可选:

要使审批规则可选,也可以使用 APIapprovals_required 属性设置为 0

受保护分支的审批#

History
    • 所有受保护分支 目标分支选项在极狐GitLab 15.3 中引入。

审批规则通常仅与特定分支相关,例如你的默认分支。要为某些分支配置审批规则:

  1. 创建审批规则
  2. 转到你的项目并选择 设置 > 合并请求
  3. 合并请求审批 部分,滚动到 审批规则
  4. 对于 目标分支
    • 要将规则应用于所有受保护分支,选择 所有受保护分支
    • 要将规则应用于特定分支,从列表中选择。
  5. 要启用此配置,请遵循 要求在受保护分支上进行代码所有者审批

安全审批#

  • Tier: 旗舰版
  • Offering: JihuLab.com,私有化部署
History
    • 安全审批移至合并请求审批设置在极狐GitLab 15.0 中引入。
    • 用于审批的机器人评论在极狐GitLab 16.2 中引入,使用名为 security_policy_approval_notification功能标志。默认启用。
    • 用于审批的机器人评论在极狐GitLab 16.3 中 GA。功能标志 security_policy_approval_notification 已移除。

可以使用合并请求审批策略根据合并请求和默认分支中漏洞的状态定义安全审批。每个安全策略的详细信息显示在合并请求配置的安全审批部分中。

安全审批规则应用于所有合并请求,直到流水线完成。安全审批规则的应用防止用户在安全扫描运行之前合并代码。流水线完成后,检查安全审批规则以确定是否仍需要安全审批。 如果流水线中的扫描程序识别出问题并需要安全审批,则会在合并请求中生成一个机器人评论,以指示需要哪些步骤来继续。

Security Approvals

这些策略都可以在安全策略编辑器中创建和编辑。

故障排除#

审批规则名称不能为空#

作为此验证错误的解决方法,可以通过 API 删除审批规则。

  1. 获取项目的规则集
  2. 删除规则

群组需要项目上的显式或继承的开发者角色#

为处理审批而创建的群组可能在项目层次结构的不同区域创建,而不是需要审查的项目。如果发生这种情况,群组的成员可能没有批准合并请求的权限,因为他们没有访问权限。

例如:

在下面的群组结构中,项目 1 属于子群组 1,子群组 4 拥有用户。

Example scenario - project and group hierarchy

项目 1 已为项目配置审批规则,将子群组 4 指定为审批者。当创建合并请求时,子群组 4 的审批者会出现在合格审批者列表中。但是,由于子群组 4 的用户无权查看合并请求,因此返回 404 错误。 要授予成员身份,必须邀请该群组作为项目成员。现在,子群组 4 的用户可以批准。

Project members page showing subgroup 4 as a member