Code Owners

原文:https://docs.gitlab.com/ee/user/project/code_owners.html

Code Owners

版本历史

Introduction

在为项目做贡献时,通常很难找出谁应该审查或批准合并请求. 此外,如果您对特定文件或代码块有疑问,可能很难知道从谁那里找到答案.

GitLab 代码所有者是一项功能,用于定义谁拥有存储库中的特定文件或路径,从而允许其他用户了解谁对每个文件或路径负责.

Why is this useful?

代码所有者允许使用版本控制的单个真实文件源,该文件概述了拥有存储库中某些文件或路径的确切 GitLab 用户或组. 可以在合并请求批准过程中利用代码所有者,该过程可以简化为给定合并请求找到合适的审阅者和批准者的过程.

在大型组织或流行的开源项目中,如果您遇到的问题可能与代码审查或合并请求批准无关,则代码所有者还可以帮助您了解与谁联系.

How to set up Code Owners

您可以使用CODEOWNERS文件来指定负责存储库中某些文件的用户或共享组 .

您可以在三个位置选择并添加CODEOWNERS文件:

  • 到存储库的根目录
  • .gitlab/目录中
  • docs/目录中

The CODEOWNERS file is scoped to a branch, which means that with the introduction of new files, the person adding the new content can specify themselves as a code owner, all before the new changes get merged to the default branch.

当一个文件与CODEOWNERS文件中的多个条目匹配时,与该文件匹配的上一个模式的用户将显示在给定文件的 Blob 页面上. 例如,您具有以下CODEOWNERS文件:

  1. README.md @user1
  2. # This line would also match the file README.md
  3. *.md @user2

将显示README.md的用户为@user2 .

Approvals by Code Owners

将”代码所有者”设置为项目后,可以将其配置为用于合并请求批准:

注意 :为了批准合并请求,需要开发人员或更高权限 .

设置后,”代码所有者”将显示在合并请求小部件中:

MR widget - Code Owners

尽管CODEOWNERS文件除了可以用于合并请求批准规则之外 ,还可以用作合并请求批准的唯一驱动程序(不使用批准规则 ). 为此,请在上面指定的三个位置之一中创建文件,并将代码所有者设置为受保护分支的必需批准者. 使用代码所有者文件的语法来指定实际所有者和精细权限.

结合使用”代码所有者”和” 受保护的分支机构批准”,将防止在CODEOWNERS文件中未指定的任何用户推送对指定文件/路径的更改,即使其角色包含在” 允许推送”列中. 这允许采用更具包容性的推送策略,因为管理员不必限制开发人员直接将其推送到受保护的分支,而可以将推送限制到某些需要代码所有者审查的文件.

The syntax of Code Owners files

可以使用与.gitignore文件中使用的相同类型的模式来指定文件,然后使用一个或多个用户的@username或电子邮件或应作为文件所有者的一个或多个组的@name进行指定. 必须将组添加为项目的成员 ,否则它们将被忽略.

GitLab 13.0开始,您现在可以将项目组层次结构中的组或子组指定为潜在的代码所有者.

例如,考虑给定项目的以下层次结构:

  1. group >> sub-group >> sub-subgroup >> myproject >> file.md

以下任何组都可以被指定为代码所有者:

  • @group
  • @group/sub-group
  • @group/sub-group/sub-subgroup

此外,使用” 成员”工具邀请到项目的任何组也将被视为合格的代码所有者.

定义路径的顺序很重要:与给定路径匹配的最后一个模式将用于查找代码所有者.

#开头的行表示注释. 需要使用\#对其进行转义,以寻址其名称以#开头的文件.

Example CODEOWNERS file:

  1. # This is an example of a code owners file
  2. # lines starting with a `#` will be ignored.
  3. # app/ @commented-rule
  4. # We can specify a default match using wildcards:
  5. * @default-codeowner
  6. # We can also specify "multiple tab or space" separated codeowners:
  7. * @multiple @code @owners
  8. # Rules defined later in the file take precedence over the rules
  9. # defined before.
  10. # This will match all files for which the file name ends in `.rb`
  11. *.rb @ruby-owner
  12. # Files with a `#` can still be accessed by escaping the pound sign
  13. \#file_with_pound.rb @owner-file-with-pound
  14. # Multiple codeowners can be specified, separated by spaces or tabs
  15. # In the following case the CODEOWNERS file from the root of the repo
  16. # has 3 code owners (@multiple @code @owners)
  17. CODEOWNERS @multiple @code @owners
  18. # Both usernames or email addresses can be used to match
  19. # users. Everything else will be ignored. For example this will
  20. # specify `@legal` and a user with email `janedoe@gitlab.com` as the
  21. # owner for the LICENSE file
  22. LICENSE @legal this_does_not_match janedoe@gitlab.com
  23. # Group names can be used to match groups and nested groups to specify
  24. # them as owners for a file
  25. README @group @group/with-nested/subgroup
  26. # Ending a path in a `/` will specify the code owners for every file
  27. # nested in that directory, on any level
  28. /docs/ @all-docs
  29. # Ending a path in `/*` will specify code owners for every file in
  30. # that directory, but not nested deeper. This will match
  31. # `docs/index.md` but not `docs/projects/index.md`
  32. /docs/* @root-docs
  33. # This will make a `lib` directory nested anywhere in the repository
  34. # match
  35. lib/ @lib-owner
  36. # This will only match a `config` directory in the root of the
  37. # repository
  38. /config/ @config-owner
  39. # If the path contains spaces, these need to be escaped like this:
  40. path\ with\ spaces/ @space-owner