第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协议(署名-相同方式共享)©