代码所有者
使用代码所有者功能来定义谁拥有项目代码库特定部分的专业知识。 定义仓库中文件和目录的所有者后,您可以方便地:
将代码所有者与合并请求批准规则(可选或必需)结合使用,可以构建灵活的批准工作流程:
- 使用代码所有者来确保质量。定义对存款中的特定路径具有领域专业知识的用户。
- 使用批准规则来定义与仓库中特定文件路径不对应的专业领域。批准规则有助于将合并请求创建者引导至正确的审核者团队,例如前端开发人员或安全团队。
例如:
类型 | 名称 | 范围 | 说明 |
---|---|---|---|
批准规则 | UX | 所有文件 | 用户体验 (UX) 团队成员评审项目中所有更改的用户体验。 |
批准规则 | Security | 所有文件 | 安全团队成员评审所有更改是否存在漏洞。 |
代码所有者批准规则 | Frontend: Code Style |
*.css 文件 |
前端工程师检查 CSS 文件更改是否符合项目样式标准。 |
代码所有者批准规则 | Backend: Code Review |
*.rb 文件 |
后端工程师评审 Ruby 文件的逻辑和代码风格。 |
查看文件或目录的代码所有者
查看文件或目录的代码所有者:
- 在左侧边栏中,选择 搜索或转到 并找到您的项目。
- 选择 代码 > 仓库。
- 转到您要查看其代码所有者的文件或目录。
- 可选。选择一个分支或标签。
极狐GitLab 在页面顶部显示代码所有者。
设置代码所有者
先决条件:
- 您必须能够推送到默认分支或创建合并请求。
CODEOWNERS
文件
CODEOWNERS
文件(没有扩展名)指定负责仓库中特定文件和目录的用户或共享群组。
每个仓库使用一个单独的 CODEOWNERS
文件。极狐GitLab 按此顺序检查仓库中的这些位置。使用找到的第一个 CODEOWNERS
文件,忽略所有其他文件:
- 在根目录中:
./CODEOWNERS
。 - 在
docs
目录中:./docs/CODEOWNERS
。 - 在
.gitlab
目录中:./.gitlab/CODEOWNERS
。
当用户或群组更改名称
当用户或群组修改其名称时,CODEOWNERS
不会自动更新,因此您必须编辑文件。
使用 SAML SSO 的组织可以设置用户名以防止用户更改用户名。
群组作为代码所有者
要将群组或子群组成员设置为代码所有者:
在 CODEOWNERS
文件中,输入符合下列模式的文本:
# All group members as Code Owners for a file
file.md @group-x
# All subgroup members as Code Owners for a file
file.md @group-x/subgroup-y
# All group and subgroup members as Code Owners for a file
file.md @group-x @group-x/subgroup-y
群组继承和资格
在示例中:
-
父组 X (
group-x
) 拥有 项目 A。 -
父组 X 也包含子组,子组 Y (
group-x/subgroup-y
)。 - 子组 Y 拥有 项目 B。
符合条件的代码所有者是:
- 项目 A:仅限 群组 X 的成员,因为 项目 A 不属于 子组 Y。
- 项目 B:群组 X 和 子组 Y 的成员。
邀请子群组加入父群组中的项目
你可以邀请 子群组 Y 加入到 项目 A 中,以便它们的成员也成为代码所有者。
如果你不邀请 子群组 Y 加入 项目 A,但将它们设置为代码所有者,它们的批准成为可选的。
邀请子群组加入父群组
邀请 子群组 Y 到 项目 A 的父群组中是不支持的。要将 子群组 Y 设置为代码所有者,请直接邀请该群组到项目本身。
为更具体定义的文件或目录定义特定的所有者
当一个文件或目录与 CODEOWNERS
文件中的多个条目匹配时,将使用来自最后一个匹配该文件或目录的样式的用户。当您以合理的方式对条目进行排序时,这使您能够为更具体定义的文件或目录定义特定的所有者。
例如,在以下 CODEOWNERS
文件中:
# This line would match the file terms.md
*.md @doc-team
# This line would also match the file terms.md
terms.md @legal-team
terms.md
的代码所有者是 @legal-team
。
通过将代码所有者设置到不同的节来组织代码所有者
changes how GitLab evaluates your Code Owners file: 在代码所有者中,部分 是文件中的命名区域,它们总是被分析和强制执行。直到您定义了一个部分,极狐GitLab 会将您的整个代码所有者文件视为一个部分。添加更多部分来更改如何评估您的代码所有者文件:
- 极狐GitLab 处理没有 section 的条目,包括在第一个部分之前定义的规则。
- 每个部分强制执行它们。
- 每个部分只匹配文件路径的一个模式。
- 在每个部分中,极狐GitLab 使用文件路径或目录的最后一个模式匹配每个 section。
比如,在使用 section 的 CODEOWNERS
文件中,让我们看看 README
文件的所有权:
* @admin
[README Owners]
README.md @user1 @user2
internal/README.md @user4
[README other owners]
README.md @user3
-
根 目录
README.md
的代码所有者是:-
@admin
,从未命名的 section。 -
@user1
和@user2
,从[README Owners]
。 -
@user3
,从[README other owners]
。
-
-
internal/README.md
的代码所有者是:-
@admin
,从未命名的 section。 -
@user4
,从[README Owners]
。 -
@user3
,从[README other owners]
。 (在[README Owners]
中的两个条目匹配此文件名,但只保留最后一个节中的条目。)
-
要在 CODEOWNERS
文件中添加一个 section,请在方括号中输入 section 名称,然后输入文件或目录,以及用户、群组或子群组:
[README Owners]
README.md @user1 @user2
internal/README.md @user2
合并请求部件中的每个代码所有者都列在标签下面。下图显示了 默认、前端 和 技术写作 section:
为 section 设置默认所有者
- 引入于极狐GitLab 15.11,使用名为
codeowners_default_owners
的功能标志。默认禁用。- 在极狐GitLab 15.11 中 GA。功能标志
codeowners_default_owners
被移除。
如果 section 中的多个文件路径拥有相同的所有权,则为此 section 定义默认的代码所有者。此 section 中的所有路径都继承此默认设置,除非您在特定行上覆盖 section 的默认设置。
当没有为文件路径指定所有者时,使用默认的所有者。在文件路径旁边定义的特定所有者会覆盖默认所有者。
比如:
[Documentation] @docs-team
docs/
README.md
[Database] @database-team @agarcia
model/db/
config/db/database-setup.md @docs-team
在此示例中:
-
@docs-team
拥有Documentation
section 中的所有项。 -
@database-team
和@agarcia
拥有Database
section 中的所有项,除了config/db/database-setup.md
,它有一个覆盖,将它分配给@docs-team
。
当在 section 中的条目不覆盖没有 section 的条目时,将此行为与一起使用常规条目和 section时相比较。
一起使用默认的所有者和可选的 section
为了将默认所有者和可选的 section 一起使用并要求审核,将默认所有者放在最后:
[Documentation][2] @docs-team
docs/
README.md
^[Database] @database-team
model/db/
config/db/database-setup.md @docs-team
一起使用常规条目和 section
如果你为 某一 section 之外的 某个路径设置了默认的代码所有者,那么他们的批准是必须的。 这些条目不会被 section 覆盖。 没有 section 的条目会被当作是另一个未命名的 section 来处理:
# Required for all files
* @general-approvers
[Documentation] @docs-team
docs/
README.md
*.txt
[Database] @database-team
model/db/
config/db/database-setup.md @docs-team
在此示例中:
-
@general-approvers
拥有所有项,没有覆盖。 -
@docs-team
拥有所有Documentation
section 中的项。 -
@database-team
拥有所有Database
section 中的项,除了config/db/database-setup.md
,它有一个覆盖,将它分配给@docs-team
。 - 修改
model/db/CHANGELOG.txt
的合并请求需要来自@general-approvers
、@docs-team
和@database-team
的三个批准。
当一个 section 中的特定条目会覆盖该章节的默认设置时,将这种行为与你仅使用 section的默认所有者时的情况进行比较。
重名的 section
如果多个 section 有相同的名称,它们会被合并。此外,section 标题不区分大小写。
[Documentation]
ee/docs/ @docs
docs/ @docs
[Database]
README.md @database
model/db/ @database
[DOCUMENTATION]
README.md @docs
这些代码会在 Documentation section 标头中出现三个条目,在 Database section 出现两个条目。 Documentation 和 DOCUMENTATION section 中的条目会使用第一个 section 中的大小写进行合并。
使代码所有者 section 可选
你可以在代码所有者文件中指定可选的部分。可选部分允许你为你的代码基础设定责任人,但不要求来自这些责任人的批准。这种方法为你的项目中的部分提供了更松散的政策,但不需要严格的审查。
要想将条目 section 作为可选的,请在 section 名称前添加 ^
字符。
在此示例中,[Go]
section 是可选的:
[Documentation]
*.md @root
[Ruby]
*.rb @root
^[Go]
*.go @root
可选的代码所有者 section 会显示在合并请求的描述下面:
如果文件中有重复的 section,且一个是可选的,另一个不是,那么这个 section 就是必须的。
CODEOWNERS
文件中的可选 section 仅在使用合并请求提交变更时是可选的。如果变更被直接提交到受保护分支上,则仍需要来自代码所有者的批准,即使 section 标记为可选的。
要要多个代码所有者审批
- 引入于极狐GitLab 15.9。
你可以在合并请求中要求多个代码所有者审批。将 section 名称和所需的人数添加到方括号中,例如 [2]
或 [3]
。这就要求 n
个来自该 section 的代码所有者审批。
有效的 n
值是 ≥ 1
。 [1]
是可选的,因为它是默认值。无效的 n
值将被视为 1
。
设置多个来自代码所有者的审批:
- 在左侧栏中选择 搜索或前往 并找到您的项目。
- 选择 设置 > 仓库。
- 扩展 受保护的分支。
- 在默认分支旁边,打开 代码所有者审批 的切换。
- 编辑
CODEOWNERS
文件以添加多个审批。
比如,要要求两个来自 [Documentation]
section 的审批:
[Documentation][2]
*.md @tech-writer-team
[Ruby]
*.rb @dev-team
审核区域中的 Documentation
代码所有者 section 显示需要两个审批。
允许推送
允许推送 的用户可以选择从他们的变更上创建合并请求,或直接推送变更到分支。如果用户跳过合并请求流程,保护分支的功能和合并请求中的代码所有者审批也会被跳过。
比权限经常授予给关联到自动化的内部用户(内部用户) 和发布工具。
所有来自 没有 允许推送 权限的用户必须经过合并请求。
相关主题
极狐GitLab 技术支持
如果您使用过程中中遇到任何问题,您可以在极狐GitLab 官方论坛上发帖求助,您也可以直接扫描下方二维码咨询专业人员: