K8s Docs

Appearance

Traefik Pull Requests 文档 ​

在提交 Pull Request 之前 ​

本指南适用于已有 pull request 要提交的贡献者。 如果你正在寻找有关设置开发环境并创建代码以贡献给 Traefik Proxy 或相关项目的信息，请参阅开发指南。

想要为 Traefik Proxy 做出贡献？ 查看此优先级 Issues 列表， Good First Issue 列表， 或等待修复的已确认 bug 列表。

我们如何确定优先级 ​

我们希望能够立即审查每个 pull request，但由于这是一个耗时的操作，这并不总是可能的。

我们能够最快处理的 PR 是：

  • 文档更新
  • Bug 修复
  • 具有 contributor/wanted 标签的增强和功能

需要更多时间处理的 PR 包括：

  • 没有 contributor/wanted 标签的增强或功能

如果你有想要构建的增强或功能的想法，请先为其创建一个 issue 并告诉我们你有兴趣编写 PR。 如果 issue 已经存在，请务必在下面评论告诉我们你有兴趣创建 PR。

这将使我们能够直接沟通并让你知道它是否是我们会接受的东西。 它还使我们能够确保你在设计阶段拥有所需的所有信息，以便它可以被快速审查和合并。

在 docs 中阅读更多关于 Triage 过程 的内容。

Pull Request 提交流程 ​

合并 PR 需要在自动合并之前完成以下步骤。

  • 确保你的 pull request 遵守我们的最佳实践。其中包括：

    • 遵循项目约定；包括使用 PR 模板。
    • 提交小的 pull request。
    • 一次只解决一个问题。
    • 充分注释。
    • 不要从组织存储库打开 PR。
    • 保持选中"允许维护者编辑"。
    • 对文档使用语义换行。
    • 确保你的 PR 不是草稿。我们不审查草稿，但会根据需要回答问题并与开发人员协商。
    • 确保 go.mod 文件中的依赖项引用标签。如果无法引用标签，请添加注释说明原因。

  • 通过验证检查。

  • 通过所有测试。

  • 收到维护者的 2 个批准审查。

Pull Request 审查周期 ​

了解我们的 Triage 过程，简而言之，它看起来像这样：

  • 我们在将每个新 PR 或评论进入审查过程之前对其进行 triage。
    • 我们确保满足审查的所有先决条件。
    • 我们检查以确保用例符合我们的需求。
    • 我们分配审查者。
  • 设计审查。
    • 这比其他部分需要更长的时间。
    • 我们审查是否存在与我们的代码库的明显冲突。
  • 代码审查。
    • 我们深入审查代码并运行测试。
    • 我们可能会在此处要求进行更改。
    • 在代码审查期间，我们要求你合理地响应， 如果 PR 在代码审查中停滞不前，它有被拒绝的风险， 或者我们可能接管 PR 的所有权，贡献者将成为合著者。
  • 合并。
    • 成功！

注意

有时，当我们朝着可能影响其它开发的特定功能或目标努力时，我们可能会冻结代码库。 在此期间，你的 pull request 可能会保持未合并状态，直到发布工作完成。

运行本地验证 ​

在提交 pull request 之前，你必须运行这些本地验证以预测持续集成的通过或失败。 在你的 PR 在 CI 上变为绿色之前，它将不会被审查。

  • make generate
  • make generate-crd
  • make test-gateway-api-conformance
  • make validate
  • make pull-images
  • make test

测试和合并工作流 ​

Pull Requests 由机器人 Myrmica Lobicornis 管理。 此机器人负责验证 GitHub Checks（CI、测试等）、可合并性和最低评论数。 此外，如果需要，它会 rebase 或与基础 PR 分支合并。 它执行其它一些内务处理任务，你可以阅读 Lobicornis 的 README 了解更多信息。

给予最终 LGTM 的维护者必须添加 status/3-needs-merge 标签以触发合并机器人。

默认情况下，将执行 squash-rebase 合并。

状态 status/4-merge-in-progress 仅由机器人使用。

如果机器人无法执行合并，则会添加标签 bot/need-human-merge。 在这种情况下，解决冲突/CI/...，然后删除标签 bot/need-human-merge。

要防止机器人自动合并 PR，请添加标签 bot/no-merge。

标签 bot/light-review 将所需 LGTM 数量从 2 减少到 1。

当以下情况时可以使用此标签：

  • 更新依赖项。
  • 将分支合并回下一个版本分支。
  • 提交小的文档更改。
  • 提交 changelog PR。

为什么我的 Pull Request 被关闭了？ ​

Traefik Proxy 由社区制作，为社区服务，因此目标是让社区参与，使 Traefik 成为最好的反向代理。 此目标的一部分是维护精简的代码库并确保代码速度。 不幸的是，这意味着有时我们将无法合并 pull request。

因为我们尊重你所做的工作，你将始终被告知我们为什么要关闭你的 pull request。 如果你不同意我们的决定，不要担心；已关闭的 pull request 可以轻松地重新创建， 并且通过关闭随后需要重新打开的 pull request，几乎没有工作丢失。

你的 pull request 可能被关闭，如果：

  • 你的 PR 的设计与我们的现有代码库冲突，导致无法合并， 并且使你的 pull request 可用所需的工作量太大。

    • 为防止这种情况，请确保先创建了 issue， 并考虑在设计阶段让 Traefik Proxy 维护者参与进来以尽量减少冲突。

  • 你的 PR 是我们不会使用的增强或功能。

    • 请记住为任何 pull request 在 创建 PR 之前 创建一个 issue， 以确保你的目标是我们可以合并的，并且你拥有团队可能需要的任何设计洞察。

  • 你的 PR 等待贡献者的反馈已超过 90 天。

为什么我的 Pull Request 没有被审查？ ​

一些因素会影响你的 pull request 可能等待审查的时间。

我们必须确定要关注哪些 PR 的优先级。 我们的首要任务是已被确定为具有高社区参与度和广泛适用性的 PR。 我们将首要任务放在我们的路线图上，你可以通过 contributor/wanted 标签识别它们。 这些 PR 将最快进入我们的审查过程。

我们的第二个优先任务是 bug 修复。 特别是已被标记为 bug/confirmed 的 bug。 这些审查会快速进入过程。

如果你的 PR 不符合上述标准， 我们将需要更长时间来审查，因为任何符合上述标准的 PR 都将被优先考虑。

此外，在里程碑的最后几周，我们停止审查 PR 以减少 churn 并稳定。 我们将在发布后恢复。

我们对你的 PR 进行降级的第二个主要原因是你没有遵循最佳实践。

未遵循最佳实践的最常见失败是：

  • 你没有为你希望制作的 PR 创建 issue。 如果你在提交 PR 之前没有创建 issue， 我们将无法回答任何设计问题并让你知道你的 PR 被合并的可能性。

  • 你创建的 pull request 太大而无法审查。

    • 拆分你的 pull request。 如果你可以从你的 pull request 中提取完整的想法并将其作为单独的 pull request 发送， 你应该这样做。 与一个 pull request 处理许多事情相比，拥有许多处理一件事的 pull request 会更好。
    • Traefik Proxy 是一个快速发展的代码库 - 尽快锁定你的更改与你的小 pull request， 并让合并成为其它人的问题。 我们希望每个 pull request 本身都是有用的， 所以请自行判断什么是 pull request 与 commit。

  • 你没有很好地评论。

    • 注释所有内容。

请记住，我们在国际、跨文化、不同的用例中工作。 你的审查者不会以与你相同的方式直观地理解问题或以与你相同的方式解决问题。 这就是为什么你所做的每一个更改都必须得到解释，并且你的编码策略也必须得到解释。

  • 你的测试不充分或缺失。
    • 如果你不知道如何测试你的 PR，请询问！ 我们很乐意帮助你或建议适当的测试用例。

如果你已经遵循了最佳实践并且你的 PR 仍然没有得到回复， 这里有一些你可以做的来推动流程的事情：

  • 如果你已修复了审查中的所有问题， 请记住重新请求审查（使用指定按钮）以让你的审查者知道你已准备好。 你可以选择评论你所做的更改。

  • 请在 pull request 上评论。这样做将在 triage 过程中自动让你的 PR 获得可见性。

有关最佳实践的更多信息，请尝试以下链接：

反驳是可以的 ​

有时审查者会犯错误。 对你审查者要求的更改进行反驳是可以的。 如果你有充分的理由以某种特定方式做事，你绝对可以辩论所请求的更改的优劣。 审查者和被审查者都应以礼貌和尊重的方式讨论这些问题。

你可能会被否决，但你可能也会占上风。 我们都是非常讲道理的人。

开源项目的另一种现象（任何人都可以对任何 issue 进行评论）是"dog-pile" - 你的 pull request 收到了来自许多人的如此多的评论以至于变得难以跟进。 在这种情况下，你可以询问主要审查者（受让人）是否希望你分叉一个新的 pull request 以清除所有评论。 你不必修复每个觉得要评论的人提出的每个问题， 但你应该以解释回答合理的评论。

常识和礼貌 ​

没有任何文档可以取代常识和良好的品味。 运用你的最佳判断，同时考虑如何使你的工作更容易审查。 如果你做了这些事情，你的 pull request 将以更少的摩擦合并。

基于 MIT 协议发布

Copyright © 2024-2026 K8s Docs