リリースプロセス
このドキュメントは、cert-manager の新しいリリースを行う際に従うべきプロセスを概説することを目的としています。現在のリリースと将来のリリースのタイムラインの詳細については、サポートされているリリースページをご覧ください。
前提条件
⛔️ 次のすべての条件を満たしていない場合は、リリースプロセスを進めないでください。
-
実行しようとしているリリースについて、関連するtestgrid ダッシュボードが失敗していない必要があります。
-
cert-manager の
govulncheckGitHubアクションは、リリースしようとしているブランチでパスしている必要があります。必要に応じて、ローカルでmake verify-govulncheckを実行してください。 -
リリースプロセスには**約40分かかります**。すべてのステップを完了するのに十分な時間が必要です。
-
cert-manager プロジェクトのGitHub
admin権限を持っている必要があります。adminロールを持っているかどうかを確認するには、以下を実行してください。brew install ghgh auth logingh api /repos/cert-manager/cert-manager/collaborators/$(gh api /user | jq -r .login)/permission | jq .permission権限が
adminの場合は、準備完了です。admin権限をcert-managerプロジェクトに要求するには、PRを作成し、ここにリンクを貼ってください。 -
GCPプロジェクトcert-manager-releaseに「エディタ」として追加されている必要があります。アクセス権限があるかどうかを確認するには、Cloud Buildページを開いてみてください。「エディタ」権限を取得するには、メンテナである必要があります。メンテナの場合は、
variables.tfのリリースマネージャリストにメールアドレスを追加したPRを作成してください。次のPRの説明を使用できます。
Title: Access to the cert-manager-release GCP projectHi. As stated in "Prerequisites" on the [release-process][1] page,I need access to the [cert-manager-release][2] project on GCP inorder to perform the release process. Thanks![1]: https://cert-manager.dokyumento.jp/docs/contributing/release-process/#prerequisites[2]: https://console.cloud.google.com/?project=cert-manager-release
このガイドは、makeを使用してリリースされたcert-managerのバージョンに適用されます。これは、cert-manager 1.8以降のすべてのバージョンです。
cert-manager 1.7以前のバージョンをリリースする必要がある場合は、旧リリースを参照してください。
ツールの設定
最初に、cert-manager のリリースを実行するために必要なすべてのツールがあることを確認してください。
-
release-notesCLIをインストールします。go install k8s.io/release/cmd/release-notes@v0.13.0 -
当社の
cmrelCLIをインストールします。go install github.com/cert-manager/release/cmd/cmrel@latest -
cert-manager/releaseリポジトリをクローンします。# Don't clone it from inside the cert-manager repo folder.git clone https://github.com/cert-manager/releasecd release -
gcloudCLIをインストールします。 -
ログインして
gcloudに接続します。gcloud auth application-default login -
gcloudがcert-manager-releaseプロジェクトを指していることを確認します。gcloud config set project cert-manager-releaseexport CLOUDSDK_CORE_PROJECT=cert-manager-release # this is used by cmrel -
こちらで、スコープを何も選択しないGitHubアクセストークンを取得します。
release-notesCLIは、すべてのPRを1つずつ処理するため、APIレート制限を回避するためにのみ使用されます。
マイナーリリース
マイナーリリースは、下位互換性のある「機能」リリースです。新しい機能とバグ修正を含めることができます。
バージョンのリリース手順
🔰 手順が不足している場合、または古くなっている場合は、このページの右上隅にある**このページを編集**ボタンをクリックしてください。
-
次の表を参照して、リリースに関する用語を確認してください。これにより、ステップの見出し（例：**（最終リリースのみ）**）を見て、どのステップをスキップできるかがわかります。
リリースの種類 gitタグの例 最初のアルファリリース v1.3.0-alpha.0その後のアルファリリース v1.3.0-alpha.1最初のベータリリース v1.3.0-beta.0その後のベータリリース v1.3.0-beta.1最終リリース v1.3.0（オプション）パッチプレリリース1 v1.3.1-beta.0パッチリリース（または「ポイントリリース」） v1.3.1 -
次のスニペットをシェルテーブルにコピーして、4つの環境変数を設定します。
export RELEASE_VERSION="v1.3.0-alpha.0"export START_TAG="v1.2.0"export END_REV="release-1.3"export BRANCH="release-1.3"注：正しい値を入力するために、次の例を使用してください。
変数 例1 例2 例2 例3 例4 最初のアルファ その後のアルファ ベータリリース 最終リリース パッチリリース RELEASE_VERSIONv1.3.0-alpha.0v1.3.0-alpha.1v1.3.0-beta.0v1.3.0v1.3.1START_TAGv1.2.0v1.3.0-alpha.0v1.3.0-alpha.1v1.2.0*v1.3.0END_REVmastermasterrelease-1.3release-1.3release-1.3BRANCHmastermasterrelease-1.3release-1.3release-1.3*パッチを使用しないでください（例：
v1.2.3）。v1.2.0にする必要があります。リリースしているリリースブランチに属する最新のタグを使用する必要があります。上記の例では、リリースブランチはrelease-1.3で、そのブランチの最新のタグはv1.2.0です。注：4つの変数は、
release-notesツールのREADMEで説明されています。便宜上、次の表に知っておくべきことをまとめています。変数 説明 RELEASE_VERSIONgitタグ START_TAG*前の*リリースのgitタグ END_REVリリースブランチ名（含む） BRANCHリリースブランチ名 -
（最終リリースのみ）ウェブサイトの「アップグレードノート」PRを準備します。
cert-manager/websiteで、新しいアップグレードドキュメントを含むPRがマージされる準備ができていることを確認してください。例として、upgrading-1.0-1.1を参照してください。
-
（最終リリースとパッチリリース）ウェブサイトの「リリースノート」PRを準備します。
⚠️ この手順は事前に実行できます。
以下の手順は、
master（**最終リリース**）またはrelease-1.x（**パッチリリース**）を使用して実行する必要があります。PRはリリース後にマージされます。以下の手順（Ctrl+Fを使用して
github-release-description.mdを検索）に従って、「github-release-description.mdの生成」セクションに進みます。2. 「依存関係」セクションを削除します。3. Markdownファイルの箇条書きごとに、変更ログのエントリを読み、リリースノートのガイドラインに従っていることを確認します。ガイドラインに従っていない変更ログのエントリが見つかった場合は、- そのPRに移動し、PRの説明を編集して
release-noteブロックの内容を変更します。 - リリースノートページに戻り、同じ変更を
release-notes.mdにコピーします（またはファイルを再生成します）。
同じ変更を
release-notes.mdにコピーします（またはファイルを再生成します）。4. 前回のリリースノートページを参考に、「主要テーマ」と「コミュニティ」のセクションを追加します。5. 次のコマンドを使用して、GitHubのissue番号とGitHubハンドル（例：#1234または@maelvls）を実際のリンクに置き換えます。sed -E \-e 's$#([0-9]+)$[#\1](https://github.com/cert-manager/cert-manager/pull/\1)$g' \-e 's$@(\w+)$[@\1](https://github.com/\1)$g' \github-release-description.md >release-notes.md-
release-notes.mdをウェブサイトのリポジトリに移動します。# From the cert-manager repo.mv release-notes.md ../website/content/docs/release-notes-1.X.md -
content/docs/manifest.jsonにエントリを追加します。{"title": "Release Notes","routes": [+ {+ "title": "v1.12",+ "path": "/docs/release-notes/release-notes-1.12.md"+ }, -
ファイル
content/docs/release-notes/README.mdに1行追加します。
- そのPRに移動し、PRの説明を編集して
-
（最終リリース＋パッチリリース）ウェブサイトの「バージョン番号の更新」PRを作成します。
⚠️ この手順は事前に実行できます。
そのPRで
-
（最終リリース）supported-releasesページの「サポートされているリリース」セクションを更新します。
-
（最終リリース）supported-releasesページの「サポートされているKubernetesバージョンの決定方法」セクションを更新します。
-
（最終リリース）
scripts/gendocs/generate-new-import-path-docsに表示されるバージョン番号を更新します。例：-LATEST_VERSION="v1.11-docs"+LATEST_VERSION="v1.12-docs"-genversionwithcli "release-1.11" "$LATEST_VERSION"+genversionwithcli "release-1.12" "$LATEST_VERSION" -
（最新のマイナーバージョンの最終リリース＋パッチリリース）
variables.jsonファイルの最新のcert-managerバージョン変数を更新します。-"cert_manager_latest_version": "v1.14.2",+"cert_manager_latest_version": "v1.14.3", -
（最終リリースのみ）
docs/フォルダのコピーを作成し、バージョン管理する必要のないページを削除し、manifest.jsonファイルを更新することで、フォルダをフリーズします。export RELEASE=1.15cp -r content/docs content/v${RELEASE}-docsrm -rf content/v${RELEASE}-docs/{release-notes,contributing}sed -i.bak "s|/docs/|/v${RELEASE}-docs/|g" content/v${RELEASE}-docs/manifest.jsonjq < content/v${RELEASE}-docs/manifest.json >/tmp/manifest \'del(.routes[0].routes[] | select(.title | test("Releases|Contributing")))'mv /tmp/manifest content/v${RELEASE}-docs/manifest.json -
（最終リリース＋パッチリリース）APIドキュメントとCLIドキュメントを更新します。
# From the website repository, on the master branch../scripts/gendocs/generate
-
-
originリモートが正しいことを確認します。これを行うには、次のコマンドを実行し、アップストリームhttps://github.com/cert-manager/cert-manager.gitが返されることを確認します。# Must be run from the cert-manager repo folder.git remote -v | grep origin表示されるはずです。
origin https://github.com/cert-manager/cert-manager (fetch)origin https://github.com/cert-manager/cert-manager (push) -
正しいブランチに切り替えます。
-
（最初のアルファ版とそれ以降のアルファ版）：
masterブランチに切り替えます。git checkout mastergit pull origin master -
（最初のベータ版のみ）リリースブランチはまだ存在しないため、作成してプッシュします。
# Must be run from the cert-manager repo folder.git checkout mastergit pull origin mastergit checkout -b release-1.12 mastergit push origin release-1.12GitHubの権限：
git pushは、cert-managerリポジトリでブランチの作成またはプッシュを行うためのadmin権限を持っている場合にのみ機能します。前提条件を参照してください。この権限がない場合は、masterブランチをリリースブランチにマージするPRを作成し、PRチェックが緑になるまで待つ必要があります。 -
（それ以降のベータ版、パッチリリース、最終リリース）：リリースブランチに切り替えます。
git checkout release-1.12git pull origin release-1.12/cherry-pick release-1.0を使用してマージされているため、ブランチを高速転送する必要はありません。コードフリーズに関する注記
最初のベータ版は、最終リリースまで続く新しい「コードフリーズ」期間を開始します。コードフリーズの直前に、masterからのすべてをリリースブランチに高速転送します。
コードフリーズ中は、通常どおりmasterにPRをマージし続けます。
2番目（およびそれ以降）のベータ版では、masterをリリースブランチに高速転送せず、
/cherry-pick release-1.0を使用して、それ以降のベータ版に含めるべき修正のみを適用します。パッチリリースと最終リリースでは高速転送を行わず、代わりに
/cherry-pick release-1.0コマンドを使用してこれらのリリースを作成します。
ブランチ保護に関する注記：リリースブランチは、GitHubブランチ保護によって保護されており、Prowによって自動的に設定されます。これにより、リポジトリ管理者であっても、誰かがこれらのブランチに誤って直接変更をプッシュすることを防ぎます。何らかの理由でリリースブランチを高速転送する必要がある場合は、GitHubブランチ保護Web UIを使用して、そのリリースブランチのブランチ保護を削除する必要があります。これは、ブランチを更新できるようにするための暫定的な変更のみです。Prowは24時間以内にブランチ保護を再適用します。
-
-
新しいリリースに必要なタグをローカルで作成し、アップストリームにプッシュします（cert-managerのビルドを開始します）。
echo $RELEASE_VERSIONgit tag -m"$RELEASE_VERSION" $RELEASE_VERSION# be sure to push the named tag explicitly; you don't want to push any other local tags!git push origin $RELEASE_VERSION注記：
git pushは、cert-managerリポジトリでブランチの作成またはプッシュを行うためのadmin権限を持っている場合にのみ機能します。前提条件を参照してください。この権限がない場合は、masterブランチをリリースブランチにマージするPRを作成し、PRチェックが緑になるまで待つ必要があります。注記2：最近のcert-managerバージョンでは、プッシュされたタグによってGoogle Cloud Buildジョブがトリガーされ、
gcb/build_cert_manager.yamlの手順を使用してビルドが開始されます。GCP上のcert-manager-releaseプロジェクトへのアクセス権を持つユーザーは、GCBビルド履歴でログを表示できます。 -
（1.12、1.13、および1.14）のみ
このステップでは、Goモジュール
github.com/cert-manager/cert-manager/cmd/ctlがサードパーティによってインポートできることを確認します。まず、一時的なブランチを作成します。
# Must be run from the cert-manager repo folder.git checkout -b "update-cmd/ctl/$RELEASE_VERSION"次に、
cmd/ctlのgo.modを、作成したばかりのタグで更新します。# Must be run from the cert-manager repo folder.cd cmd/ctlgo get github.com/cert-manager/cert-manager@$RELEASE_VERSIONcd ../..make tidygit add "**/go.mod" "**/go.sum"git commit --signoff -m"Update cmd/ctl's go.mod to $RELEASE_VERSION"次に、cert-managerのフォークにブランチをプッシュします。例：
# Must be run from the cert-manager repo folder.gh repo fork --remote-name forkgit push -u fork "update-cmd/ctl/$RELEASE_VERSION"次に、その変更をマージするPRを作成し、次のコマンドを使用してリリースブランチに戻ります。
gh pr create \--title "[Release $RELEASE_VERSION] Update cmd/cmctl's go.mod to $RELEASE_VERSION" \--body-file - --base $BRANCH <<EOFThis PR cmd/cmctl's go.mod to $RELEASE_VERSION as part of the release process.**To the reviewer:** the version changes in \`go.mod\` must be reviewed.\`\`\`release-noteNONE\`\`\`EOFPRがマージされるまで待ちます。
最後に、
cmd/ctlモジュールのタグを作成します。# Must be run from the cert-manager repo folder.git fetch origin $BRANCHgit checkout $BRANCHgit pull --ff-only origin $BRANCHgit tag -m"cmd/ctl/$RELEASE_VERSION" "cmd/ctl/$RELEASE_VERSION" origin/$BRANCHgit push origin "cmd/ctl/$RELEASE_VERSION"注記：これを行う必要がある理由は、Stack Overflowで説明されています。how-are-versions-of-a-sub-module-managed
-
このセクションでは、GitHubリリースの説明を作成します。
注記：このステップは、GitHubリリースページにコピーアンドペーストする説明を作成することです。ウェブサイト上の「リリースノート」ページの作成は、前のステップで行われます。
-
4つの環境変数がすべて準備できていることを確認します。
echo $RELEASE_VERSIONecho $START_TAGecho $END_REVecho $BRANCH -
次のコマンドを使用して
github-release-description.mdを生成します。# Must be run from the cert-manager folder.export GITHUB_TOKEN=$(gh auth token)git fetch origin $BRANCHexport START_SHA="$(git rev-list --reverse --ancestry-path $(git merge-base $START_TAG $BRANCH)..$BRANCH | head -1)"release-notes --debug --repo-path cert-manager \--org cert-manager --repo cert-manager \--required-author "cert-manager-prow[bot]" \--markdown-links=false \--output github-release-description.mdGitHubトークンには**スコープは不要**です。トークンは、匿名APIユーザーに課せられるレート制限を回避するためにのみ必要です。
-
先頭に1文のサマリーを追加します。
-
（最終リリースのみ）v1.12.0などの過去のリリースを参考に、「コミュニティ」セクションを作成します。コードへの貢献はなかったものの、その他の方法（テスト、PRの議論など）で支援してくれたユーザーがいれば、ここで感謝の意を表しましょう！
-
-
タグをプッシュしたときに自動的にトリガーされたビルドが完了したことを確認し、リリースに関するSlackメッセージを送信します。
-
#cert-manager-devに最初のSlackメッセージを送信します。1.2.0-alpha.2リリース 🧵 -
GCBビルド履歴でビルドが完了したことを確認します。
🔰 ビルドログには、非難されたままになっているデータが含まれている可能性があるため、簡単に確認してください。機密データは適切に非難されるようにしていますが、更新し忘れることもあります。
-
ビルドログのURLをコピーし、この最初のメッセージに返信して、Cloud Buildジョブのリンクを含む2番目のSlackメッセージを送信します。たとえば、メッセージは次のようになります。
-
-
cmrel publishを実行します。-
ステージングされたリソースがすべて有効であることを確認するために、
cmrel publishのドライランを実行します。次のコマンドを実行します。# Must be run from the "cert-manager/release" repo folder.cmrel publish --release-name "$RELEASE_VERSION"このコマンドの出力にあるGoogle Cloud Build URLをクリックすると、進捗状況を確認できます。
-
ビルドの実行中は、最初のメッセージに返信して3番目のSlackメッセージを送信します。
-
ここで、リリースアーティファクトを実際に公開します。次のコマンドは、アーティファクトをGitHub、
Quay.io、およびHelmチャートリポジトリに公開します。# Must be run from the "cert-manager/release" repo folder.cmrel publish --nomock --release-name "$RELEASE_VERSION" -
ビルドの実行中は、最初のメッセージに返信して4番目のSlackメッセージを送信します。
-
-
GitHubリリースを公開する
-
ドラフトのGitHubリリースにアクセスし、先に生成したリリースノートを貼り付けます。以前のリリースのスタイルに合わせるために、内容を手動で編集する必要があります。特に、パッケージ関連の変更は削除してください。
-
(最初のアルファ版、以降のアルファ版およびベータ版のみ) 「これはプレリリースです」チェックボックスをオンにします。
-
(最終リリースとパッチリリース) 「最新リリースとして設定」チェックボックスをオンにします。
-
「公開」をクリックして、GitHubリリースを公開します。
-
-
Helmチャートを含むプルリクエストをマージする
重要: 現在、このPRはVenafiの従業員のみがマージできますが、近いうちに修正する予定です。これを変更するには、Helmチャートの保存場所の移行計画を立て、誰にも支障が出ないようにする必要があります。
cert-managerのHelmチャートはCloudflare Pagesを使用して提供されており、HelmチャートファイルとメタデータはJetstackチャートリポジトリに保存されています。
cmrel publish --nomockステップ（上記）により、このリポジトリにPRが作成されます。これを以下のようにレビューしてマージする必要があります。- プルリクエストにアクセスする
- 変更内容を確認する
- 失敗しているチェックを修正する
- チャートをテストする
- プルリクエストからチャートのtarballをダウンロードする
- 新しいローカルKindクラスタを起動する
kind create cluster --name release - KindクラスタにHelmチャートをインストールする
helm install cert-manager ./cert-manager-v0.15.0.tgz --set crds.enabled=true -n cert-manager - インストールが成功し、すべてのコンポーネントが実行されていることを確認する
- Kindクラスタを削除する
kind delete cluster --name release
- PRをマージする
- ArtifactHUBでcert-manager Helmチャートが表示されていることを確認する。
-
(最終リリースとパッチリリース) 4つのウェブサイトPRをマージする
-
先に作成した「リリースノート」、「アップグレードノート」、「バージョン凍結とバンプ」のPRをマージします。
-
ここをクリックして、「release-nextをmasterにマージ」PRを作成します。
dco-signoff: noラベルが表示された場合、PRに以下のコメントを追加します。/override dcoこのコマンドは、一部のマージコミットがボットによって作成され、DCO署名がないため必要です。
-
-
1.14以前の場合のみ
Homebrew の
cmctl用フォーミュラアップデートのPRを開きます。ℹ️
latestバージョンのcert-managerを公開している場合は、PRは自動的に作成されます。このステップはスキップできます。ただし、以前のバージョンのパッチを公開する場合は、スキップできません。brewがインストールされていると仮定して、brew bump-formula-prコマンドを使用できます。新しいタグ名と、そのタグのコミットハッシュが必要です。brew bump-formula-pr --helpで最新の情報を参照してください。コマンドは次の形式になります。brew bump-formula-pr --dry-run --tag v0.10.0 --revision da3265115bfd8be5780801cc6105fa857ef71965 cmctlタグとリビジョンを新しいものに変更します。
Homebrewチームによるレビューには時間がかかります。https://github.com/homebrew/homebrew-coreに対するプルリクエストが開かれたら、リリース手順を続けます。
-
最初のメッセージに対する回答としてSlackメッセージを投稿します。「
#cert-manager-devにも送信」チェックボックスをオンにして、メッセージがはっきりと表示されるようにします。#cert-managerにもクロス投稿します。 -
(最終リリースのみ) リリースを世間に公開する
-
releaseラベル付きのメールをcert-manager-dev@googlegroups.comに送信します（例）。 -
cert-managerのTwitterアカウントでツイートを送信します！ログイン詳細はJetstackの1passwordにあります（今のところ）。(ツイートの例)。 @JetstackHQがリツイートするようにしてください！
-
cert-managerのMastodonアカウントからトゥートを送信します！ログイン詳細はJetstackの1passwordにあります（今のところ）。(トゥートの例)
-
-
リリース後の「テストとリリース」手順に進みます。
-
(最初のベータ版のみ) 定期的なProwJobsのリストに新しいリリースを追加するために、cert-manager/testingでPRを作成します。このPRを例として使用します。
make prowgenコマンドを実行して、新しい設定を生成する必要があります。 -
(最終リリースのみ) サポートされていないリリースバージョンをprow設定から削除するために、cert-manager/testingでPRを作成します。
-
(最終リリースのみ)
cert-manager/testingで、milestone_applier設定を確認し、masterで新しく作成されたPRが次のリリースの新しいマイルストーンに適用されるようにします。リリースブランチとTestgridダッシュボード設定に必要なステータスチェックも確認します。
次のリリースのマイルストーンが存在しない場合は、最初に作成します。リリースしたバージョンのマイルストーンが完了したと判断した場合は、閉じます。
-
これのようなKrewインデックスに対するPRを開き、kubectlプラグインのバージョンを上げます。これは、cmctl/kubectlプラグインの機能が大幅に変更された場合、または新しいメジャーバージョンの最初のリリース後に行う価値があります。
-
新しいOLMパッケージを作成し、OperatorHubに公開する
cert-managerはOperator Lifecycle Manager（OLM）を使用してインストールできます。そのため、各cert-managerバージョンに対してOLMパッケージを作成し、
operatorhub.ioとRedHat OpenShiftの同等のパッケージインデックスの両方に公開する必要があります。cert-manager OLMリリースプロセスに従い、公開後、cert-manager OLMインストール手順がまだ機能することを確認します。
-
旧リリース
上記のガイドは、v1.8以降のcert-managerバージョンにのみ適用されます。
旧バージョンはBazelを使用して構築されており、このビルドプロセスの違いはリリースプロセスに反映されています。
cert-manager 1.6および1.7
このウェブサイトのガイドではなく、GitHubの旧バージョンのリリースプロセスに従ってください。
最も顕著な違いは、cmrel makestageではなくcmrel stageを呼び出すことです。cmrelの最新バージョンを使用してリリースしても問題ありません。
cert-manager 1.5以前
バージョン1.5以前をリリースする場合は、異なるバージョンのcmrelをインストールする必要があります。
cmrelをインストールする手順では、代わりに次のコマンドを実行します。
go install github.com/cert-manager/release/cmd/cmrel@cert-manager-pre-1.6
これにより、使用しているcmrelのバージョンが、リリースするcert-managerのバージョンと互換性があるようになります。
cert-manager/releaseリポジトリをチェックアウトする手順では、そのリポジトリのcert-manager-pre-1.6タグをチェックアウトする必要があります。
git checkout cert-manager-pre-1.6
異なるcert-manager/releaseタグとcmrelバージョンを除いて、1.6と1.7で使用されているのと同じ旧リリースドキュメントに従うことができます。インストールするcmrelのバージョンを変更することを忘れないでください！
脚注
-
バグ修正またはセキュリティ修正を一般公開する前に、ボランティアのコミュニティテストを可能にするために、1つ以上の「パッチプレリリース」を作成できます。パッチプレリリースには、
-betaサフィックスを使用する必要があります。↩
