第69节 GitHub 中 OWNERS 文件


❤️💕💕记录sealosopen in new window开源项目的学习过程。k8s,docker和云原生的学习open in new window。Myblog:http://nsddd.topopen in new window


[TOC]

介绍

团队开发中,我们熟悉的术语有哪些?

termsmeans翻译
WIPWork in progress, do not merge yet.开发中
LGTMLooks good to me.Riview 完别人的 PR,没有问题,可以合并了
PTALPlease take a look.帮我看下,一般都是请别人 review 自己的 PR
CCCarbon copy一般代表抄送别人的意思
RFCrequest for comments.我觉得这个想法很好, 我们来一起讨论下
IIRCif I recall correctly.如果我没记错
ACKacknowledgement.我确认了或者我接受了,我承认了
NACK/NAKnegative acknowledgement.我不同意

这些术语挺有意思的,还可以通过术语学习一下单词。

OWNERS 文件

k8s 使用 owners 文件的灵感来自于Chromium OWNERS文件open in new window

owners 文件主要是为了解决代码审查过程中的问题:

  1. 项目中代码审查的速度, 受到能够审查代码的人员数量的限制;
  2. 一个人的代码审查的质量受到他们对所审查代码的熟悉程度的限制。

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 false if not present; if true, exclude parent OWNERS files. Allows the use case where a/deep/nested/OWNERS file prevents a/OWNERS file from having any effect on a/deep/nested/bit/of/code
  • lreviewers: a list of GitHub usernames or aliases that are good candidates to /lgtm a 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 文件主要区别是:

  1. CODEOWNERS 文件是 GitHub 提供的,它使用了 GitHub 的代码所有权功能。而 OWNERS 文件是 Git 本身的一个约定,GitHub 识别并提供了支持。
  2. CODEOWNERS 文件支持更加精细的模式匹配,可以匹配文件路径,文件扩展名,甚至文件内容。而 OWNERS 只支持基本的文件路径匹配。
  3. CODEOWNERS 中列出的审核者可以是个人用户,团队,也可以是外部的电子邮件地址。 OWNERS 只支持 GitHub 用户和团队。
  4. 更新 CODEOWNERS 文件会自动通知被指定为所有者的人员。而 OWNERS 文件需要人工通知。
  5. CODEOWNERS文件中的审核者列表仅控制与文件相关的代码更改的审核者,而不是整个目录或仓库。当有人向仓库推送包含CODEOWNERS规则的文件更改时,GitHub会自动请求列出的审核者来review这些更改。
  6. 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 链接