新着：プロジェクトの最新情報はTwitterとMastodonで入手してください。

貢献フロー

cert-manager の開発はすべて、コード、問題、プルリクエストを含む GitHub 経由で行われています。

ドキュメントと cert-manager.io のすべてのコードは、cert-manager/website リポジトリにあります。ドキュメントに関する問題も、そこに提出する必要があります。

GitHub ボット

すべてのリポジトリで Prow を使用しています。Kubernetes リポジトリを見たことがあれば、おそらく Prow にすでに遭遇しているでしょう。Prow は、コマンドを使用して GitHub であなたを支援することができます。それらはすべて コマンドヘルプページで見つけることができます。Prow はすべてのテストを実行し、PR に特定のラベルを割り当てます。

バグ

すべてのバグは、GitHubリポジトリ内のイシューとして追跡する必要があります。イシューには、kind/bugタグを付ける必要があります。これを行うには、イシューの説明に/kind bugを追加します。これにより、優先度とマイルストーンが割り当てられ、将来のリリースで対処されるようになります。

バグがどのように発見されたかについて、より多くのログと情報を提供していただければ、より迅速に解決することができます。

重大なバグ修正は、通常、現在のマイナー安定リリースにもチェリーピックされます。

注意：単にトラブルシューティングをお探しの場合は、コミュニティのcert-manager Slackチャンネルに質問を投稿してください。GitHubイシューよりも多くの人がこのチャンネルを読んでおり、Slackを使用することで問題がより早く解決する可能性があります。また、イシュー検索バーでキーワードを検索して、バグがすでに報告されていないか確認してください。

イシューの(再)オープンとクローズ

Prowは、あなたが提出したイシューを再オープンまたはクローズするのを支援できます。GitHubイシューのコメントで/reopenまたは/closeを使用してトリガーできます。

機能

機能リクエストは、GitHubイシューとして作成する必要があります。リクエストする機能の明確な動機と、その実装方法に関するいくつかの可能な解決策を含める必要があります。イシューには、kind/featureのタグを付ける必要があります。これを行うには、イシューの説明に/kind featureを追加します。

注意：機能リクエストがすでに作成されているか、プロジェクトの優先順位と一致しているかどうかを議論するために、コミュニティのcert-manager Slackチャンネルで機能リクエストを取り上げることをお勧めします。

プルリクエストの作成

cert-managerのコードベースへの変更は、プルリクエストを介して行われます。各プルリクエストには、このプルリクエストで修正される対応するイシューが添付されているのが理想的です。コード変更を自己完結させ、レビューを簡素化するために、複数のプルリクエストで単一のイシューを解決することは有効です。

作成されると、チームメンバーがレビューのために自分自身を割り当て、テストを有効にします。変更が確実にマージされるように、複数回繰り返される可能性のあるレビューに注意してください。

プルリクエストが重大なバグ修正である場合、これはパッチリリースとして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:**（太字テキストに注意）で始める必要があります。

チェリーピッキング

プルリクエストに重大なバグ修正が含まれている場合は、これを現在の安定したcert-managerブランチにチェリーピックし、パッチリリースとしてリリースする必要があります。

チェリーピックプロセスをトリガーするには、GitHub PRにコメントを追加します。例：

/cherry-pick release-x.y

jetstack-botは、新しいブランチとリリースブランチに対するPRを作成します。これは、上記で説明したプロセスを使用してレビュー、承認、およびマージする必要があります。

DCO署名

PRのすべてのコミットは署名される必要があります。これを行う方法の詳細については、DCO署名ページを参照してください。例外は、小さなドキュメント修正に対してのみ許可されます。

プロジェクト管理

cert-managerのプロジェクト管理のほとんどは、Prowの助けを借りてGitHubで行われます。

いつ何かがリリースされるのか？

私たちのチームはGitHubマイルストーンを使用して作業しています。イシューにマイルストーンが設定されている場合、通常、これは私たちがこれに対処する計画があることを示しています。ProwはマージされたPRにマイルストーンを適用します。これにより、PRがどのバージョンに組み込まれるかがわかります。

マイルストーンページには、リリース予定日が示されています。これには遅延が生じる可能性があります。ユーザー/コントリビューターには、隔週のコミュニティミーティングでこれについて説明します。最新のステータスレポートについては、これらのミーティングに参加することをお勧めします。

ラベル

PRとイシューには、GitHubラベルを多用しています。PRのラベルは主にProwとコードレビュアーによって管理されています。イシューでは、常にarea、priority、kindの3つのタイプを追加することを目指しています。これらは、Prowを使用して/area、/kind、/priorityを使用して設定されます。フォローアップイシューの際に役立つ/triageが追加されることもあります。

  • Areaは、変更が必要なコード領域を示します。
  • Kindは、それがbugかfeatureかを示しますが、documentationまたはcleanup（一般的なメンテナンス）である場合もあります。
  • Priorityは、cert-managerチームにとっての優先度であり、PRも非常に歓迎しています！

PRとイシューにおけるアサインの意味

時々、/assign prowコマンドを使用してコメントしている人がいるかもしれません。

/assign @meyskens

GitHubアサインに与えている意味は次のとおりです。

  • イシューでは、アサインされた人がそれに取り組んでいることを意味します。
  • PRでは、常に誰がPRを確認する必要があるかを知る方法として使用します。
    • 著者がアサインされている場合、それはPRに作業が必要、つまり「変更リクエスト」があることを意味します。
    • 誰もアサインされていない場合、それはこのPRがレビューを必要としていることを意味します。
    • 著者とは異なる人がアサインされている場合、それはこの人がこのPRをレビューしていることを意味します。

トリアージパーティー！

数週間ごとに、トリアージパーティーのミーティングを計画します。そこでは、(トリアージパーティー)[https://triage.build-infra.jetstack.net/]ツールを使って、最近の/古いIssueを優先順位付けし、タイムリーに対処できるようにします。これらのミーティングは誰でも参加可能で、メーリングリストを使って招待状が送られます（注意：パーティーという言葉にもかかわらず、これらのミーティングは時には退屈です）。