第69节 GitHub 中 OWNERS 文件
❤️💕💕记录sealos开源项目的学习过程。k8s,docker和云原生的学习。Myblog:http://nsddd.top
[TOC]
介绍
团队开发中,我们熟悉的术语有哪些?
| terms | means | 翻译 | 
|---|---|---|
| WIP | Work in progress, do not merge yet. | 开发中 | 
| LGTM | Looks good to me. | Riview 完别人的 PR,没有问题,可以合并了 | 
| PTAL | Please take a look. | 帮我看下,一般都是请别人 review 自己的 PR | 
| CC | Carbon copy | 一般代表抄送别人的意思 | 
| RFC | request for comments. | 我觉得这个想法很好, 我们来一起讨论下 | 
| IIRC | if I recall correctly. | 如果我没记错 | 
| ACK | acknowledgement. | 我确认了或者我接受了,我承认了 | 
| NACK/NAK | negative acknowledgement. | 我不同意 | 
这些术语挺有意思的,还可以通过术语学习一下单词。
OWNERS 文件
k8s 使用 owners 文件的灵感来自于Chromium OWNERS文件
owners 文件主要是为了解决代码审查过程中的问题:
- 项目中代码审查的速度, 受到能够审查代码的人员数量的限制;
- 一个人的代码审查的质量受到他们对所审查代码的熟悉程度的限制。
owners:
每个包含一个独立代码或内容单元的目录也可能包含一个OWNERS文件。该文件适用于目录中的所有内容,包括OWNERS文件本身,同级文件和子目录。
OWNERS 文件使用 YAML 格式,并且支持如下关键字:
- approvers: 一组Github的用户名或者别名,他们能够 /approve一个 PR
- labels: a list of GitHub labels to automatically apply to a PR
- options: a map of options for how to interpret this OWNERS file, currently only one: - no_parent_owners: defaults to falseif not present; iftrue, exclude parent OWNERS files. Allows the use case wherea/deep/nested/OWNERSfile preventsa/OWNERSfile from having any effect ona/deep/nested/bit/of/code
 
- no_parent_owners: defaults to 
- lreviewers: a list of GitHub usernames or aliases that are good candidates to /lgtma PR
💡简单的一个案例如下:
approvers:
  - alice
  - bob     # this is a comment
reviewers:
  - alice
  - carol   # this is another comment
  - sig-foo # this is an alias
最佳实践
- team aliases are used that correspond to sigs
- reviewers 最好多于 approvers
- 批准者不在 reviewers区块中
- OWNERS 文件会定期更新 (至少每次发布变更一次)
Reference
See the OWNERS docs at https://go.k8s.io/owners
CODEOWNERS 文件
CODEWONERS 文件是 GitHub 提供的,并且有相关的文档说明:
CODEOWNERS 文件和 OWNERS 文件主要区别是:
- CODEOWNERS文件是 GitHub 提供的,它使用了 GitHub 的代码所有权功能。而- OWNERS文件是 Git 本身的一个约定,GitHub 识别并提供了支持。
- CODEOWNERS文件支持更加精细的模式匹配,可以匹配文件路径,文件扩展名,甚至文件内容。而- OWNERS只支持基本的文件路径匹配。
- CODEOWNERS中列出的审核者可以是个人用户,团队,也可以是外部的电子邮件地址。- OWNERS只支持 GitHub 用户和团队。
- 更新 CODEOWNERS文件会自动通知被指定为所有者的人员。而OWNERS文件需要人工通知。
- CODEOWNERS文件中的审核者列表仅控制与文件相关的代码更改的审核者,而不是整个目录或仓库。当有人向仓库推送包含- CODEOWNERS规则的文件更改时,GitHub会自动请求列出的审核者来review这些更改。
- OWNERs文件控制整个目录或仓库的审核者,而不仅仅是与文件相关的更改。当有人向仓库提交代码更改时,GitHub会根据- OWNERS文件中的规则来确定哪些人需要审查和批准更改。
除此之外,这两个文件在作用上是完全相同的:指定目录或文件的审核责任人。
Note
所以总体来说,建议优先使用
CODEOWNERS文件,因为它支持更丰富的功能,并且有 GitHub 的官方支持。OWNERS文件仅在需要兼容 Git 本身的情况下使用。两者也可以同时存在,GitHub 会同时识别。但如果有规则冲突,会以CODEOWNERS文件为准。
CODEOWNERS 文件语法:
CODEOWNERS 文件通常包含两列:
第一列是文件模式,用于匹配目录下的文件。例如:
- *表示匹配所有文件
- *.go匹配所有- .go后缀的文件
- dir/匹配- dir目录下的所有文件
第二列是审核者列表,用于指定谁可以审核匹配的文件。可以是个人的 GitHub 用户名,也可以是团队名。例如:
- @octocat表示 GitHub 用户名为- octocat的用户
- @github/team-name表示 GitHub 的- team-name团队
END 链接
- ✴️版权声明 © :本书所有内容遵循CC-BY-SA 3.0协议(署名-相同方式共享)©