NEW: 在Twitter和Mastodon获取项目更新。

贡献流程

cert-manager 的所有开发都通过 GitHub 进行，其中包含代码、问题和拉取请求。

所有文档和 cert-manager.io 的代码都可以在 cert-manager/website 仓库 中找到。所有关于文档的问题也应该在那里提交。

GitHub 机器人

我们在所有仓库中使用 Prow。如果你曾经查看过 Kubernetes 仓库，你可能已经遇到过 Prow。Prow 可以通过其命令帮助你在 GitHub 上使用。你可以在 命令帮助页面 上找到它们。Prow 还会运行所有测试并在 PR 上分配某些标签。

错误

所有错误都应该作为问题跟踪在 GitHub 仓库中。问题应该附加 kind/bug 标签。为此，请在你的问题描述中添加 /kind bug。然后它可能会被分配优先级和里程碑，以便在将来的版本中解决。

你可以提供的关于错误如何被发现的日志和信息越多，它就能越快被解决。

关键错误修复通常也会被 cherry-pick 到当前的次要稳定版本。

注意：如果你只是在寻找故障排除，那么你应该将你的问题发布到社区 cert-manager Slack 频道。阅读该频道的人比 GitHub 问题多得多，使用 Slack 解决问题可能会更快。请也检查一下该错误是否已经通过在问题搜索栏中搜索关键词来提交。

（重新）打开和关闭问题

Prow 可以帮助你重新打开或关闭你提交的问题，你可以在 GitHub 问题评论中使用 /reopen 或 /close 来触发它。

功能

功能请求应该作为 GitHub 问题创建。它们应该包含你想要看到的功能的明确动机，以及一些关于如何实现它的可能解决方案。问题应该用 kind/feature 标签标记。为此，请在你的问题描述中添加 /kind feature。

注意：通常在社区 cert-manager Slack 频道 上提出你的功能请求是一个好主意，以讨论该功能请求是否已经被提出或是否与项目的优先级一致。

创建拉取请求

cert-manager 代码库的更改是通过 拉取请求 完成的。每个拉取请求都应该理想地附带一个相应的已解决问题。多个拉取请求可以解决单个问题，以保持代码更改自包含，更易于审查。

创建后，团队成员会将自己分配为审查者并启用测试。为了确保更改被合并，请关注审查，审查可能会有多个循环。

如果拉取请求是关键错误修复，那么这可能也会被 cherry-pick 到当前的 cert-manager 稳定版本作为补丁版本发布。

为了让大家知道你的 PR 仍在进行中，我们通常会在 PR 标题中添加 WIP: 前缀。然后 Prow 会自动设置 do-not-merge/work-in-progress 标签。

发布说明指南

PR 描述中的 release-note 代码块旨在向最终用户解释他们是否应该关心此更改以及他们是否会受到影响。只要用良好的英语（主语谓语宾语，以句号结尾）写成，有多个句子是可以的。

发布说明块不应该仅仅复述提交消息。例如，最终用户不知道“比较”是什么，以及哪些自定义资源受到影响。

```release-note
Adds missing comparisons for certain fields which were incorrectly skipped if a LiteralSubject was set
```

一个更好的发布说明块提供了上下文，并具体告诉最终用户他们将如何受到影响。

```release-note
When using the `literalSubject` on a Certificate, the IPs, URIs, DNS names, and email addresses subject segments are now properly compared.
```

发布说明块中的换行符会转换为硬换行符，这意味着无法软换行发布说明。换行符对列表很有用。

```release-note
cainjector:
- New flags were added to the cainjector binary. They can be used to modify what injectable kinds are enabled. If cainjector is only used as a cert-manager's internal component it is sufficient to only enable validatingwebhookconfigurations and mutatingwebhookconfigurations injectable resources; disabling the rest can improve memory consumption. By default all are enabled.
- The `--watch-certs` flag was renamed to `--enable-certificates-data-source`.
```

如果此 PR 引入了重大更改，则发布说明块必须以 **BREAKING:**（注意粗体文本）开头。

Cherry-pick

如果拉取请求包含关键错误修复，则应将其 cherry-pick 到当前的 cert-manager 稳定分支中，并 作为补丁版本发布。

要触发 cherry-pick 过程，请在 GitHub PR 中添加评论。例如

/cherry-pick release-x.y

jetstack-bot 然后将创建一个新的分支，以及一个针对发布分支的 PR，应该使用上面描述的过程进行审查、批准和合并。

DCO 签署

PR 中的所有提交都应该签署，有关如何执行此操作的更多信息，请访问 DCO 签署 页面。只有对小的文档修复才能例外。

项目管理

cert-manager 的大部分项目管理是在 GitHub 上进行的，并在 Prow 的帮助下完成。

什么时候发布？

我们的团队使用 GitHub 里程碑 进行工作。当在问题上设置里程碑时，通常意味着我们计划在何时解决这个问题。Prow 会在合并的 PR 上应用里程碑，这将告诉你 PR 将在哪个版本中发布。

里程碑页面还将显示我们发布的预计截止日期。这可能会有一些延迟。我们在双周社区会议上向用户/贡献者简要介绍此事，对于最新的状态报告，我们建议你加入这些会议。

标签

我们大量使用 GitHub 标签来标记 PR 和问题。PR 上的标签主要由 Prow 和代码审查人员管理。在问题中，我们总是力求添加 3 种类型：区域、优先级和种类。这些是使用 Prow 使用 /area、/kind 和 /priority 来设置的。有时也会添加 /triage，它在跟进问题时很有帮助。

  • 区域指示需要更改的代码区域。
  • 种类指示它是一个 bug 还是一个 feature，但也可以是 documentation 或 cleanup（一般维护）。
  • 优先级是 cert-manager 团队对它的优先级，PR 仍然非常受欢迎！

PR 和问题中的受让人意义

有时，你可能会看到有人使用 /assign prow 命令 评论。

/assign @meyskens

以下是我们对 GitHub 受让人员的理解。

  • 在问题中，这意味着受让人员正在处理它。
  • 在 PR 上，我们使用它来了解任何时候谁应该查看 PR。
    • 当作者被分配时，这意味着 PR 需要工作才能完成，也就是“需要更改”；
    • 当没有人被分配时，这意味着此 PR 需要审查；
    • 当与作者不同的人被分配时，这意味着此人正在审查此 PR。

分拣派对！

每隔几周，我们会计划一次分拣派对会议，在那里我们会使用 (分拣派对)[https://triage.build-infra.jetstack.net/]工具来处理最近/旧的问题，以便我们能够及时解决它们。这些会议对所有人开放，邀请将通过我们的邮件列表发送（警告：尽管有“派对”这个词，但这些会议有时很无聊）。