最新消息：在Twitter和Mastodon取得專案更新

貢獻流程

cert-manager 的所有開發工作都是透過 GitHub 完成的，其中包含程式碼、問題和提取請求。

所有關於文件和 cert-manager.io 的程式碼都可以在 cert-manager/website 儲存庫 中找到。 任何關於文件的問題也應該在此處提出。

GitHub 機器人

我們在所有的儲存庫上使用 Prow。 如果您曾經看過 Kubernetes 儲存庫，您可能已經接觸過 Prow。 Prow 將能夠使用其命令在 GitHub 中為您提供幫助。 您可以在命令說明頁面上找到它們。 Prow 還將執行所有測試，並在 PR 上分配某些標籤。

錯誤

所有錯誤都應在 GitHub 儲存庫中作為 issue 追蹤。 然後應在 issue 中附加 kind/bug 標籤。 為此，請在您的 issue 描述中新增 /kind bug。 然後，這可能會被分配一個優先順序和里程碑，以便在未來版本中解決。

您提供的關於如何發現錯誤以及錯誤的更多日誌和資訊，可以更快地解決它。

嚴重的錯誤修復通常也會被挑選到目前次要的穩定版本中。

注意：如果您只是在尋找疑難排解，那麼您應該將您的問題發佈到社群 cert-manager slack 頻道。閱讀這個頻道的人比 GitHub issues 多得多，使用 Slack 您的問題可能會更快得到解決。另請檢查是否已透過在 issue 搜尋欄中搜尋關鍵字來提交錯誤。

（重新）開啟和關閉 issue

Prow 可以幫助您重新開啟或關閉您提交的 issue，您可以使用 GitHub Issue 評論中的 /reopen 或 /close 來觸發它。

功能

功能請求應建立為 GitHub issue。它們應包含您希望看到的功能的明確動機，以及如何實作的一些可能解決方案。然後應使用 kind/feature 標記 issue。為此，請在您的 issue 描述中新增 /kind feature。

注意：最好在社群 cert-manager slack 頻道中提出您的功能請求，以討論是否已提出該功能請求或是否符合專案的優先順序。

建立提取請求

對 cert-manager 程式碼庫的變更透過 提取請求完成。每個提取請求最好都有一個相應的 issue，該 issue 將由這個提取請求修復。為了保持程式碼變更的自我包含性和更容易審查，多個提取請求解決單一 issue 是有效的。

建立完成後，團隊成員將為自己分配審查並啟用測試。為確保變更合併，請注意可能有多個週期的審查。

如果提取請求是嚴重的錯誤修復，那麼這也可能會被挑選到目前穩定版本的 cert-manager 作為修補程式版本。

為了讓大家知道您的 PR 仍在進行中，我們通常會在 PR 的標題中新增 WIP: 字首。然後，Prow 將自動設定標籤 do-not-merge/work-in-progress。

發行說明指南

PR 描述中的 release-note 程式碼區塊旨在向最終用戶說明他們是否應該關心這個變更以及他們是否會受到影響。只要以良好的英文撰寫（主詞、動詞、補語，並以句點結尾），有多個句子是可以的。

發行說明區塊不應該只是改寫 commit 訊息。例如，最終用戶不知道「比較」是什麼以及哪些自訂資源受到影響。

```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:** 開頭（請注意粗體文字）。

挑選變更

如果提取請求包含嚴重的錯誤修復，則應將其挑選到目前的穩定 cert-manager 分支，並以修補程式版本發行。

若要觸發挑選變更的程序，請在 GitHub PR 中新增評論。例如

/cherry-pick release-x.y

jetstack-bot 隨後將建立一個新的分支，並建立一個針對發行分支的 PR，該 PR 應使用上述流程進行審查、核准和合併。

DCO 簽署

PR 中的所有 commit 都應簽署，有關如何執行的更多資訊，請參閱DCO 簽署頁面。 只有在小的文件修復的情況下才能例外。

專案管理

cert-manager 的大多數專案管理都在 GitHub 上完成，並在 Prow 的協助下完成。

什麼時候會發佈內容？

我們的團隊使用 GitHub 里程碑工作。當在 issue 上設定里程碑時，通常表示我們計畫何時處理此問題。Prow 將在已合併的 PR 上套用里程碑，這將告訴您該 PR 將在哪個版本中發佈。

里程碑頁面也會指示我們將發布的截止日期。這可能會有些延遲。我們在每兩週一次的社群會議中向用戶/貢獻者簡要介紹此內容，如需最新的狀態報告，我們建議您加入這些會議。

標籤

我們大量使用 GitHub 標籤來管理 PR (Pull Request，拉取請求) 和 Issue (議題)。PR 上的標籤主要由 Prow 和程式碼審閱者管理。在 Issue 中，我們的目標是始終加入 3 種類型：area（區域）、priority（優先順序）和 kind（類型）。這些標籤會使用 Prow，透過 /area、/kind 和 /priority 指令設定。有時也會加入 /triage 標籤，這有助於我們追蹤 Issue。

  • Area 指示需要或將需要變更的程式碼區域。
  • Kind 指示是 bug (錯誤) 還是 feature (功能)，但也可能是 documentation (文件) 或 cleanup (一般維護)。
  • Priority 是 cert-manager 團隊的優先順序，但我們仍然非常歡迎所有 PR！

PR 和 Issue 中 Assignees 的含義

有時，您可能會看到有人使用 /assign Prow 命令來留言。

/assign @meyskens

以下是我們賦予 GitHub 受讓人 (assignees) 的含義：

  • 在 Issue 上，表示受讓人正在處理該 Issue。
  • 在 PR 上，我們將其用作了解誰應該隨時查看 PR 的方式。
    • 當作者被指派時，表示 PR 需要完成工作，也就是「請求變更」。
    • 當沒有人被指派時，表示此 PR 需要審閱。
    • 當指派的人不是作者時，表示此人正在審閱此 PR。

分類派對！

每隔幾週，我們就會計劃一次分類派對會議，我們將使用 (分類派對) [https://triage.build-infra.jetstack.net/]。工具來處理最近/舊的 Issue，以便將它們優先處理，以便我們能及時解決。這些會議對所有人開放，邀請函將透過我們的郵件列表發出（警告：儘管名為派對，但這些會議有時會很無聊）。