From dc2960f5c54430988c4b25ded5a822196b54c51d Mon Sep 17 00:00:00 2001 From: Mini256 Date: Sun, 28 Nov 2021 22:57:52 +0800 Subject: [PATCH] docs: add dco / rerere doc (#784) part of #423 --- docs/README.md | 5 +- docs/_sidebar.md | 1 + docs/components/rerere.md | 4 +- docs/en/README.md | 52 +++++++++++---------- docs/en/_sidebar.md | 2 + docs/en/components/rerere.md | 91 ++++++++++++++++++++++++++++++++++++ docs/en/plugins/dco.md | 74 +++++++++++++++++++++++++++++ docs/en/plugins/wip.md | 2 +- docs/plugins/dco.md | 73 +++++++++++++++++++++++++++++ docs/plugins/wip.md | 2 +- 10 files changed, 275 insertions(+), 31 deletions(-) create mode 100644 docs/en/components/rerere.md create mode 100644 docs/en/plugins/dco.md create mode 100644 docs/plugins/dco.md diff --git a/docs/README.md b/docs/README.md index fd284a164..a78d906b8 100644 --- a/docs/README.md +++ b/docs/README.md @@ -15,7 +15,7 @@ 以下展示的是 TiDB 社区当中较为常用的一些组件或插件,其中名称以 `ti-community-` 开头的外部插件是 TiDB 社区 [Community Infra SIG](https://developer.tidb.io/SIG/community-infra) 开发并正在维护的插件。如果你在使用过程中遇到任何问题,你都可以在 [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=sig-community-infra&ref=github) 当中与我们取得联系。 | 插件名称 | 插件类型 | 功能简介 | -| ------------------------------- | -------- | --------------------------------------------------------------------------------------------- | +|---------------------------------|----------|-----------------------------------------------------------------------------------------------| | tide | 基础组件 | 通过一些给定条件来管理 GitHub PR 池,自动合并符合条件的 PR。 | | rerere | 基础组件 | 将代码 push 到专门用来重新测试的分支上进行重新测试。 | | ti-community-owners | 外部插件 | 根据 SIG 或 Github 权限等信息来确定 PR 的 reviewer 和 committer。 | @@ -28,7 +28,7 @@ | ti-community-label-blocker | 外部插件 | 主要负责阻止用户对某些敏感标签的进行非法操作。 | | ti-community-label-contribution | 外部插件 | 主要负责为外部贡献者的 PR 添加 `contribution` 或 `first-time-contributor` 标签。 | | ti-community-cherrypicker | 外部插件 | 主要负责将 PR cherry-pick 到其他目标分支。 | -| ti-community-format-checker | 外部插件 | 主要负责将 PR 或 Issue 的标题、内容以及提交信息的格式进行检查。 | +| ti-community-format-checker | 外部插件 | 主要负责将 PR 或 Issue 的标题、内容以及提交信息的格式进行检查。 | | needs-rebase | 外部插件 | 当 PR 需要进行 rebase 时,通过添加标签或添加评论提醒 PR 作者进行 rebase。 | | require-matching-label | 内置插件 | 当 PR 或 Issue 缺失相关标签时,通过添加标签或评论提醒贡献者进行补充。 | | hold | 内置插件 | 通过 `/[un]hold` 命令,添加或取消 PR 的不可合并状态。 | @@ -38,6 +38,7 @@ | wip | 内置插件 | 为正在开发的 PR 添加 `do-not-merge/work-in-progress` 标签,阻止自动分配 reviewer 和 PR 合并。 | | welcome | 内置插件 | 通过机器人向首次贡献的贡献者发送欢迎语。 | | release-note | 内置插件 | 主要负责检测 PR 是否添加了发布说明。 | +| dco | 内置插件 | 检查 PR 的所有 commit 是否都签署邮箱地址。 | | label_sync | 工具 | 能够将 yaml 文件当中配置的标签同步到一个或多个仓库。 | | autobump | 工具 | 通过自动提交 Pull Request 的方式更新上游 Prow 及其相关组件和插件的版本。 | diff --git a/docs/_sidebar.md b/docs/_sidebar.md index c5df20662..a9d453352 100644 --- a/docs/_sidebar.md +++ b/docs/_sidebar.md @@ -22,6 +22,7 @@ - [assign](plugins/assign.md) - [milestone](plugins/milestone.md) - [release-note](plugins/release-note.md) + - [dco](plugins/dco.md) - [工具](tools.md) - [label_sync](tools/label_sync.md) - [autobump](tools/autobump.md) diff --git a/docs/components/rerere.md b/docs/components/rerere.md index b960131aa..996475cdb 100644 --- a/docs/components/rerere.md +++ b/docs/components/rerere.md @@ -13,12 +13,12 @@ 为了解决上述问题我们开发了 [tars](plugins/tars.md) 来自动的合并最新 的 Base 分支到 PR,这样能解决问题,但是对于大型仓库来说这不是一个高效的解决方案。**例如有 n 个同时可以 merge 的 PR,那就要跑 O(n^2) 次测试,大大浪费了 CI 资源。** -为了高效的合并 PR,并且节省测试资源,我们提出了[多个解决方案](https://github.com/ti-community-infra/rfcs/discussions/13)。最终决定利用 Prow Job 结合 Tide 来解决该问题。 +为了高效的合并 PR,并且节省测试资源,我们提出了[多个解决方案](https://github.com/ti-community-infra/rfcs/discussions/13) 。最终决定利用 Prow Job 结合 Tide 来解决该问题。 ## 设计思路 1. Prow Job 会利用 [clonerefs](https://github.com/kubernetes/test-infra/tree/master/prow/clonerefs) 工具将 PR 和最新的 Base 分支合并之后克隆到运行测试的 Pod,所以我们总是能够获取到已经合并了最新 Base 的代码库,rerere 可以将该代码 push 到重新测试分支进行合并之前的测试。 -2. Porw Job 可以设置 max_concurrency 来控制该 CI 任务最多的执行个数,这是一个天然的 FIFO 队列,我们可以利用该功能对重新测试任务排队。 +2. Porw Job 可以设置 `max_concurrency` 来控制该 CI 任务最多的执行个数,这是一个天然的 FIFO 队列,我们可以利用该功能对重新测试任务排队。 3. Tide 在代码合并之前,会检测所有的 Prow Job 是否都使用了最新的 Base 进行了测试。如果当前 CI Pod 使用的不是最新的 Base,Tide 会自动重新触发该测试,这样就确保了所有的 PR 在合并之前都会用最新的 Base 重新测试。 4. 在 rerere 中我们会将代码 push 到指定的测试分支,然后定期检查要求的 CI 是否都已经通过,当所有要求的 CI 都通过时,我们 rerere 的 Prow Job 就会通过测试。Tide 则会自动合并当前 PR。 diff --git a/docs/en/README.md b/docs/en/README.md index 52fe70427..400aff66f 100644 --- a/docs/en/README.md +++ b/docs/en/README.md @@ -16,31 +16,33 @@ The TiDB community has customized a number of its own plugins based on this feat The following shows some commonly used components or plugins in the TiDB community. The external plugins whose name begin with `ti-community-` are developed and maintained by the [Community Infra SIG](https://developer.tidb.io/SIG/community-infra) of TiDB community. If you encounter any problems during use, you can contact us in [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=sig-community-infra&ref=github). -| plugin name | plugin type | introduction | -|-----------------------------|-----------------|-------------------------------------------------------------------------------------------------------------------------------------------| -| tide | basic component | Manage the GitHub PR pool through some given conditions and automatically merge PR that meets the conditions. | -| ti-community-owners | external plugin | Determine the reviewer and committer of the PR based on information such as SIG or Github permissions. | -| ti-community-lgtm | external plugin | Add, update or delete the `status/LGT*` label by submitting Approve or Request Changes review. | -| ti-community-merge | external plugin | Add or delete the `status/can-merge` label for PR by command. | -| ti-community-blunderbuss | external plugin | Mainly responsible for automatically assigning reviewers based on SIG or Github permissions. | -| ti-community-autoresponder | external plugin | Automatically reply based on the content of the comment. | -| ti-community-tars | external plugin | Mainly responsible for automatically merging the main branch into the current PR to ensure that the current PR's Base is kept up to date. | -| ti-community-label | external plugin | Add labels to PR or Issue via commands. | -| ti-community-label-blocker | external plugin | Mainly responsible for preventing users from illegal operations on certain sensitive labels. | -| ti-community-contribution | external plugin | Mainly responsible for adding `contribution` or `first-time-contributor` labels to the PRs of external contributors. | -| ti-community-cherrypicker | external plugin | Mainly responsible for cherry-pick PR to other target branches. | -| ti-community-format-checker | external plugin | Mainly responsible for checking the title, content and format of the commit message of the PR or issue. | -| needs-rebase | external plugin | When the PR needs to rebase, add labels or add comments to remind the PR author to rebase. | -| require-matching-label | internal plugin | When a PR or Issue lacks a relevant label, add a label or comment to remind contributors to supplement. | -| hold | internal plugin | Add or cancel the non-combinable status of PR through the `/[un]hold` command. | -| assign | internal plugin | Add or cancel the assignee of PR or Issue through the `/[un]assign` command. | -| size | internal plugin | Evaluate the size of the PR based on the number of lines of code modification, and label the PR with `size/*`. | -| lifecycle | internal plugin | Use labels to mark the life cycle of Issue or PR. | -| wip | internal plugin | Add the `do-not-merge/work-in-progress` label to the PR under development to prevent the automatic assignment of reviewer and PR merge. | -| welcome | internal plugin | Send a welcome message to contributors who have contributed for the first time through a robot. | -| release-note | internal plugin | It is mainly responsible for detecting whether a PR has added a release note. | -| label_sync | tool | Able to synchronize the labels configured in the yaml file to one or more repositories. | -| autobump | tool | Update the version of upstream Prow and its related components and plugins by automatically submitting Pull Requests. | +| plugin name | plugin type | introduction | +|-----------------------------|-----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------| +| tide | basic component | Manage the GitHub PR pool through some given conditions and automatically merge PR that meets the conditions. | +| rerere | basic component | Push the code to a branch dedicated to re-testing for re-testing. | +| ti-community-owners | external plugin | Determine the reviewer and committer of the PR based on information such as SIG or Github permissions. | +| ti-community-lgtm | external plugin | Add, update or delete the `status/LGT*` label by submitting Approve or Request Changes review. | +| ti-community-merge | external plugin | Add or delete the `status/can-merge` label for PR by command. | +| ti-community-blunderbuss | external plugin | Mainly responsible for automatically assigning reviewers based on SIG or Github permissions. | +| ti-community-autoresponder | external plugin | Automatically reply based on the content of the comment. | +| ti-community-tars | external plugin | Mainly responsible for automatically merging the main branch into the current PR to ensure that the current PR's Base is kept up to date. | +| ti-community-label | external plugin | Add labels to PR or Issue via commands. | +| ti-community-label-blocker | external plugin | Mainly responsible for preventing users from illegal operations on certain sensitive labels. | +| ti-community-contribution | external plugin | Mainly responsible for adding `contribution` or `first-time-contributor` labels to the PRs of external contributors. | +| ti-community-cherrypicker | external plugin | Mainly responsible for cherry-pick PR to other target branches. | +| ti-community-format-checker | external plugin | Mainly responsible for checking the title, content and format of the commit message of the PR or issue. | +| needs-rebase | external plugin | When the PR needs to rebase, add labels or add comments to remind the PR author to rebase. | +| require-matching-label | internal plugin | When a PR or Issue lacks a relevant label, add a label or comment to remind contributors to supplement. | +| hold | internal plugin | Add or cancel the non-combinable status of PR through the `/[un]hold` command. | +| assign | internal plugin | Add or cancel the assignee of PR or Issue through the `/[un]assign` command. | +| size | internal plugin | Evaluate the size of the PR based on the number of lines of code modification, and label the PR with `size/*`. | +| lifecycle | internal plugin | Use labels to mark the life cycle of Issue or PR. | +| wip | internal plugin | Add the `do-not-merge/work-in-progress` label to the PR under development to prevent the automatic assignment of reviewer and PR merge. | +| welcome | internal plugin | Send a welcome message to contributors who have contributed for the first time through a robot. | +| release-note | internal plugin | It is mainly responsible for detecting whether a PR has added a release note. | +| dco | internal plugin | Check whether all commits of the PR have signed off by email addresses. | +| label_sync | tool | Able to synchronize the labels configured in the yaml file to one or more repositories. | +| autobump | tool | Update the version of upstream Prow and its related components and plugins by automatically submitting Pull Requests. | At the same time, you can find all currently available components or plugins in [Plugins](https://prow.tidb.io/plugins) page, or in [Command](https://prow.tidb.io/command-help) to view the commands available in the specified repository. diff --git a/docs/en/_sidebar.md b/docs/en/_sidebar.md index 48e5846e4..f10dd52b1 100644 --- a/docs/en/_sidebar.md +++ b/docs/en/_sidebar.md @@ -1,5 +1,6 @@ - [Components](en/components.md) - [Tide](en/components/tide.md) + - [rerere](en/components/rerere.md) - [Plugins](en/plugins.md) - External - [ti-community-owners](en/plugins/owners.md) @@ -21,6 +22,7 @@ - [assign](en/plugins/assign.md) - [milestone](en/plugins/milestone.md) - [release-note](en/plugins/release-note.md) + - [dco](en/plugins/dco.md) - [tools](tools.md) - [label_sync](en/tools/label_sync.md) - [autobump](en/tools/autobump.md) diff --git a/docs/en/components/rerere.md b/docs/en/components/rerere.md new file mode 100644 index 000000000..41e0c794c --- /dev/null +++ b/docs/en/components/rerere.md @@ -0,0 +1,91 @@ +# rerere + +[rerere](https://github.com/ti-community-infra/tichi/tree/master/internal/pkg/rerere) is a core component of tichi, rerere will push the code to a branch dedicated to retesting Re-test on. It will run as a [Prow Job](https://github.com/kubernetes/test-infra/blob/master/prow/jobs.md). + +## design background + +This component was developed to solve the problem of multiple PR merging mentioned in [Tide](components/tide.md): + +- PR1: Rename bifurcate() to bifurcateCrab() +- PR2: call bifurcate() + +At this time, both PRs will use the current master as the Base branch for testing, and both PRs will pass. But once PR1 is merged into the master branch first, after the second PR merges (because the test also passed), it will cause the master to fail to find `bifurcate` error. + +In order to solve the above problems, we developed [tars](plugins/tars.md) to automatically merge the latest Base branch to PR, which can solve the problem, but it is not an efficient solution for large repositories. **For example, if there are n PRs that can be merged at the same time, then O(n^2) tests must be run, which greatly wastes CI resources. ** + +In order to efficiently merge PR and save test resources, we propose [multiple solutions](https://github.com/ti-community-infra/rfcs/discussions/13). Finally decided to use Prow Job combined with Tide to solve the problem. + +## Design ideas + +1. Prow Job will use the [clonerefs](https://github.com/kubernetes/test-infra/tree/master/prow/clonerefs) tool to merge the PR and the latest Base branch and then clone it to the Pod running the test, so We can always get the code base that has merged the latest Base, rerere can push the code to the retest branch for testing before the merge. +2. Porw Job can set `max_concurrency` to control the maximum number of executions of the CI task. This is a natural FIFO queue. We can use this function to queue up retest tasks. +3. Before the code is merged, Tide will check whether all Prow Jobs are tested using the latest Base. If the current CI Pod is not using the latest Base, Tide will automatically re-trigger the test, which ensures that all PRs will be retested with the latest Base before merging. +4. In rerere, we will push the code to the designated test branch, and then regularly check whether all required CIs have passed. When all required CIs have passed, our rerere Prow Job will pass the test. Tide will automatically merge the current PR. + +## Parameter configuration + +| Parameter name | Type | Description | +| ---------------- | ------------- | ---------------------------------------------------------------------------- | +| retesting-branch | string | Branch name for retesting | +| retry | int | The number of retries after the retest timeout | +| timeout | time.Duration | timeout for each retest attempt | +| labels | []string | Labels that must be present before retesting (for example: status/can-merge) | +| require-contexts | []string | The name of the required CI task | + + +Fox example: + +```yaml +presubmits: + tikv/tikv: + -name: pull-tikv-master-rerere + decorate: true + trigger: "(?mi)^/(merge|rerere)\\s*$" + rerun_command: "/rerere" + max_concurrency: 1 # Run at most one task at the same time + branches: + -^master$ + spec: + containers: + -image: ticommunityinfra/rerere-component:latest + command: + -rerere + args: + ---github-token-path=/etc/github/token + ---dry-run=false + ---github-endpoint=https://api.github.com + ---retesting-branch=master-retesting + ---timeout=40m + ---require-contexts=tikv_prow_integration_common_test/master-retesting + ---require-contexts=tikv_prow_integration_compatibility_test/master-retesting + ---require-contexts=tikv_prow_integration_copr_test/master-retesting + ---require-contexts=tikv_prow_integration_ddl_test/master-retesting + volumeMounts: + -name: github-token + mountPath: /etc/github + readOnly: true + volumes: + -name: github-token + secret: + secretName: github-token +``` + +## Reference documentation + +- [Code Implementation](https://github.com/ti-community-infra/tichi/tree/master/internal/pkg/rerere) + +## Q&A + +### Will rerere be triggered every time I submit? + +Yes, but we will not actually push to the test branch for testing before we hit `status/can-merge`. The test will be skipped because of the lack of required labels. When the `/merge` command is used, the CI will be triggered again. At this time, because there is already a `status/can-merge`, we will actually re-test. + +### If the test fails, do I still need `/merge`? + +No, after using Tide, we don't need to use `/merge` continuously, just trigger the test again if a test fails. For example, if the rerere test fails, you only need to re-trigger `/rerere` to make it retest. + +### After I merge the PR manually, will it cause problems in the queue for retesting? + +No, except for the PR that you manually merged will be affected, other PRs will detect the Base change before the merge, and Tide will automatically re-trigger rerere for testing. + +**It is strongly recommended not to merge PR manually, just re-trigger after the test fails. When all required CIs pass, Tide will try to merge again. ** \ No newline at end of file diff --git a/docs/en/plugins/dco.md b/docs/en/plugins/dco.md new file mode 100644 index 000000000..56932696d --- /dev/null +++ b/docs/en/plugins/dco.md @@ -0,0 +1,74 @@ +# dco (Developer Certificate of Origin) + +## Background + +> DCO is the abbreviation of [Developer Certificate of Origin](https://developercertificate.org/), which was established in 2004 by the Linux Foundation. Compared to signing a CLA agreement, contributors do not need to read lengthy legal provisions, but only need to sign the email address in the commit message in the format of `Signed-off-by: Random ` when submitting the code. , To alleviate the hindrance of developers' contribution. + + +In order to ensure that code contributors sign all commits when submitting a Pull Request, the managers of open source warehouses usually check all the commits of the PR through CI checks or GitHub Bot. + +For example: [probot/dco](https://github.com/probot/dco) robot which is widely used for DCO Check. Unfortunately, the original team of the DCO robot no longer maintains the project ([probot/dco#162](https://github.com/probot/dco/issues/162#issuecomment-941149056) ), and GitHub have shutdown the server of the Probot App. + +If you want to continue using this Probot App, you need to deploy it yourself. As an alternative, we can directly open the dco plugin on the repositories where TiChi has been deployed to implement the same check. + +## Design + + +Contributors can add the `-s` parameter to the command line that submits the Commit, and the git command will automatically add the signing information. + +```bash +git commit -s -m'This is my commit message' +``` + +```bash +This is my commit message + +Signed-off-by: Random +``` + +When contributors submit code through PR, the robot will check the submitted commit. If it finds that one of the commit messages does not contain the `Signed-off-by:` field, the robot will list out no-signed commits through comment. + +Contributors can use [`git commit --amend`](https://docs.github.com/en/github/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message) and other methods to resign-off the commits. + +When all commits have been signed off, the robot will change the status of `dco` to passed. + +![doc_all_commits_signed_off](https://user-images.githubusercontent.com/5086433/143772523-3eeaf9f0-3021-4eb9-9c9d-81f2ce7878cc.png) + +## Configuration + +The DCO check for Org members or collaborators can be skipped through configuration. + +```yaml +dco: + org/repo: + # Skip the DCO check for project collaborators + skip_dco_check_for_collaborators: true + # Skip the DCO check for project members + skip_dco_check_for_members: true + # Specify the members of Org to skip the DCO check. When the skip_dco_check_for_members option is enabled, the members of the organization where the current warehouse is located are skipped by default + trusted_org: org +``` + +Under normal circumstances, open source warehouses using DCO agreements will make all commits in the PR must be signed as one of the necessary conditions for PR merger. To achieve this feature, you can use GitHub's branch protection mechanism to use the status of `dco` as [Required Context Status](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging). + +In the TiDB community, we use the [branchprotector](components/branchprotector.md) component to manage branch protection. You can add `dco` to the corresponding repository's [`required_status_checks`](https://github.com/ti-community-infra/configs/blob/main/prow/config/config.yaml#:~:text=branch-protection) Among the configuration items, the robot will be in the PR merged *half an hour * The warehouse branch protection is automatically set up inside. + +```yaml +branch-protection: + orgs: + ti-community-infra: + repos: + test-dev: + branches: + master: + protect: true + required_status_checks: + contexts: + -"dco" + # other status check... +``` + +## Reference Documents + +- [dco doc](https://prow.tidb.io/plugins?repo=ti-community-infra%2Ftichi) +- [code](https://github.com/kubernetes/test-infra/tree/master/prow/plugins/dco) \ No newline at end of file diff --git a/docs/en/plugins/wip.md b/docs/en/plugins/wip.md index 10f50a4a6..30e598617 100644 --- a/docs/en/plugins/wip.md +++ b/docs/en/plugins/wip.md @@ -1,4 +1,4 @@ -# wip(Work In Process) +# wip (Work In Process) ## Design Background diff --git a/docs/plugins/dco.md b/docs/plugins/dco.md new file mode 100644 index 000000000..b169e5793 --- /dev/null +++ b/docs/plugins/dco.md @@ -0,0 +1,73 @@ +# dco (Developer Certificate of Origin) + +## 设计背景 + +> DCO 是 [Developer Certificate of Origin](https://developercertificate.org/) 的缩写,由 Linux Foundation 于 2004 年制定。相比签署 CLA 协议,贡献者不需要阅读冗长的法律条文,只需要在提交代码时在 commit message 中以 `Signed-off-by: Full Name ` 格式签署邮件地址即可,减轻开发者贡献的阻碍。 + + +为了能够确保代码贡献者在提交 Pull Request 时对所有的 commit 都进行了签署,开源仓库的管理者通常会通过 CI 检查或 GitHub Bot 来对 PR 的所有 commit 进行检查。 + +例如:被广泛用于 DCO 检查的 [probot/dco](https://github.com/probot/dco) 机器人。但是不幸的是,DCO 机器人的原创团队已经不再继续维护该项目 ( [probot/dco#162](https://github.com/probot/dco/issues/162#issuecomment-941149056) ),GitHub 方面也关闭了该 Probot App 的服务器,想要继续使用该 Probot App 则需要自行部署。 + +作为替代方案,我们可以在已经部署了 TiChi 的仓库上直接开启 dco 插件来实现同等的检查功能。 + +## 设计思路 + +贡献者可以在提交 Commit 的命令行当中添加 `-s` 参数,git 命令将会自动添加上签署信息。 + +```bash +git commit -s -m 'This is my commit message' +``` + +```bash +This is my commit message + +Signed-off-by: Random +``` + +当贡献者通过 PR 的方式提交代码时,机器人会对提交的 commit 进行检查,如果发现其中一个 commit 的 commit message 部分没有带有 `Signed-off-by: ` 字段,机器人将会通过评论列举出没有签署信息的 commit 列表。 + +贡献者可以通过 [`git commit --amend`](https://docs.github.com/en/github/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message) 等方式对 commit 进行重新签署。 + +当所有的 commit 都已经签署后,机器人会将 `dco` 的状态变成通过状态。 + +![doc_all_commits_signed_off](https://user-images.githubusercontent.com/5086433/143772523-3eeaf9f0-3021-4eb9-9c9d-81f2ce7878cc.png) + +## 参数配置 + +可以通过配置跳过对 Org 成员或协作者的 DCO 检查。 + +```yaml +dco: + org/repo: + # 跳过对项目协作者的 DCO 检查 + skip_dco_check_for_collaborators: true + # 跳过对项目成员的 DCO 检查 + skip_dco_check_for_members: true + # 指定 Org 的成员可以跳过 DCO 检查,当 skip_dco_check_for_members 选项开启时,默认跳过当前仓库所在组织的成员 + trusted_org: org +``` + +一般情况下,使用 DCO 协议的开源仓库都会将 PR 中所有 commit 必须都经过签署作为 PR 合并的必要条件之一。要想实现该功能,可以利用 GitHub 的分支保护机制,将 `dco` 这个 Status 作为 [Required Context Status](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging) 。 + +在 TiDB 社区当中,我们使用 [branchprotector](components/branchprotector.md) 组件来对分支保护进行管理,可以在启动 dco 插件的同时,将 `dco` 添加到对应仓库的 [`required_status_checks`](https://github.com/ti-community-infra/configs/blob/main/prow/config/config.yaml#:~:text=branch-protection) 配置项当中,机器人将会在 PR 合并后的 *半小时* 内自动地将仓库分支保护设置好。 + +```yaml +branch-protection: + orgs: + ti-community-infra: + repos: + test-dev: + branches: + master: + protect: true + required_status_checks: + contexts: + - "dco" + # other status check... +``` + +## 参考文档 + +- [dco doc](https://prow.tidb.io/plugins?repo=ti-community-infra%2Ftichi) +- [代码实现](https://github.com/kubernetes/test-infra/tree/master/prow/plugins/dco) diff --git a/docs/plugins/wip.md b/docs/plugins/wip.md index fcdd17011..05c37f532 100644 --- a/docs/plugins/wip.md +++ b/docs/plugins/wip.md @@ -1,4 +1,4 @@ -# wip(Work In Process) +# wip (Work In Process) ## 设计背景