release-kotlin-library

Kotlin ライブラリをリリースする

基本原則

準備、検証、ユーザー承認が完了したリリースコミットを公開します。成果物と Git の状態を検証してから、リリース完了とします。

前提条件

このスキルでは、ローカルで実行する場合も、タグをトリガーとする CI を通じて実行する場合も、ライブラリの公開に gradle-maven-publish-plugin（com.vanniktech.maven.publish）を使用します。 API スナップショットのサポートには、Metalava が生成する api/api.txt ファイルが必要です。リポジトリでこれらのファイルを管理していない場合は、スナップショットを無効にしてください。

手順

1. 作業範囲を確定し、リポジトリーの指示、Git の状態、リリース履歴、バージョンプロパティ、公開設定、必須チェックを確認します。 ユーザーが提供された状態のみを対象にレビューするよう指定した場合は、コマンドを実行せず、提供されていない状態は不明として記録します。公開対象のモジュールに com.vanniktech.maven.publish が直接、またはコンベンションプラグイン経由で適用されていることを、ビルドファイルまたは提供されたリポジトリー情報から確認します。宣言があるだけでは不十分です。適用されていない、または確認できない場合はその旨を報告し、リリースに関わる変更の前に停止します。公開プラグインのインストールや移行は行いません。 準備状況のレビュー、準備、明示的なリリース承認を区別し、続行する前に該当する終了パスを選びます。 リカバリーまたはリカバリーレビューでは、分析前に リカバリー回答フォームを選択して読みます。変更履歴に関するレビューでは、変更履歴の手順も読みます。 準備または変更履歴のみの作業では、分析前に 準備回答フォームを別の呼び出しで最後まで読みます。 認証情報を含め、レビューは読み取り専用で行います。既存のローカルまたは CI の公開方法に従い、移行は行いません。付属スクリプトを設定する前に ヘルパーの契約を読みます。 サポートされていないレイアウトや宛先が曖昧な場合は、変更の前に停止します。
2. 準備の前に、変更履歴の手順を最後まで読み、ベースライン、バージョン、対象範囲の曖昧さを解消します。推測したり、変更履歴を作成したりしないでください。
3. テスト、および設定されている場合は Metalava API の生成と互換性チェックを含め、リポジトリーのリリースチェックを特定します。スナップショットを作成する前に、API ファイルが最新であることを確認します。ヘルパーは Metalava を実行せず、API ファイルをコピーするだけです。他の API ダンプ形式を Metalava のスナップショットとして扱わないでください。リリース対象コードに対して合格した証拠を必須とします。関連する変更が加わった後では、親コミットのチェックが成功していても不十分です。Gradle の実行には gradle-runを使用し、スキャンが明示的に許可されていない限り --no-scan を指定します。許可された範囲内で失敗したチェックを修正します。それ以外の場合は、失敗したゲートと次の対応を示して停止します。
4. 明示的なバージョン、パス、見出しスタイル、API スナップショットの適用対象、ブランチ、リモート、タグ、コマンド引数を指定して、ヘルパーを設定し、事前確認を行います。設定と証拠は、追跡対象のリリースファイルの外に保管します。書き込み前に、インデックス、スナップショットの衝突、ローカルとリモートの宛先を確認します。ローカル公開では ~/.env をデータとして読み込み、シェルでソースしたり、その内容を表示したりしないでください。明示的に設定されたプロセス環境変数は維持します。必須の認証情報がない場合はローカル公開をブロックします。その値を求めたり、ログに記録したりしないでください。タグをトリガーとする CI では、既存の Git 認証と CI 管理の公開シークレットを使用し、ローカルの dotenv 値を読み込んだり、必須としたりしないでください。
5. リリースを準備します。バージョンを更新し、変更履歴の見出しを確定し、該当する公開対象モジュールの API スナップショットを更新して、設定済みのチェックを実行し、リリースファイルのみをコミットします。安定版リリース項目を確定する際は、対象サイクルの元のプレリリース項目を <details> ブロック内の <summary>Prerelease history</summary> の下にまとめる前に、カバレッジ台帳で残っている各行について、最終的な動作を表す表現で安定版の概要を作成します。元のプレリリース項目は順序を変えず、ひとまとまりのブロックとして移動します。見出し、アンカー、日付、本文はそのまま維持し、ブロック内の Markdown の前後には空行を入れます。古い安定版リリースはブロックの外に置きます。レンダラーが折りたたみ可能な HTML に対応していない場合は、項目を展開したままにします。引き継ぐ前に、実際の安定版概要が台帳の残りの各行を反映していること、およびまとめた履歴が元の順序どおりであることを再確認します。検証はこの状態に結び付け、関連するコードが変更された場合は無効にします。準備中にヘルパーが公開を行ってはなりません。
6. 公開前に、準備したリリースをユーザーに提示し、明示的な承認を得ます。リリースバージョンとタグ、確定した変更履歴（または変更履歴がないこと）、次の開発バージョン、リリースコミット、アーティファクトの座標と宛先、公開方法、検証結果を提示します。準備ができたという説明だけでなく、実際のリリースノートまたは直接レビューできる差分を提示します。このスキルで承認ゲートが必須であることを説明し、ユーザーの判断を待ちます。リリースするという一般的な依頼は、未確認のリリース詳細への承認にはなりません。この準備済みリリースそのものに対する承認がすでに得られている場合は、それを再利用します。コード、バージョン、変更履歴、公開範囲に変更があった場合は、リリースを改めて準備して検証し、再度承認を得ます。準備のみ、または準備状況の確認を求められた場合は、公開承認を求めず、指定された範囲で終了します。
7. 準備済みリリースが承認され、すべてのゲートに合格したら、そのコミットからリポジトリーで選択された方法を使って公開します。ローカル公開とタグをトリガーとする CI は代替手段です。両方を実行してはなりません。承認前にアーティファクトを公開したり、リリースタグをプッシュしたり、公開 CI をトリガーしたりしないでください。
8. 設定済みの宛先で、期待されるすべてのアーティファクトの座標とバージョンを検証し、該当する場合は CI の完了も確認します。リモートタグが準備済みのコミットを参照していることを確認します。コマンドの成功やタグだけでは、アーティファクトの証拠にはなりません。その後に限り、合意済みの次の開発バージョンへ進め、その変更をコミット、プッシュし、検証します。リポジトリーの慣例で GitHub Release が必要な場合に限り、確定したリリースノートを使って作成し、読み戻して確認します。
9. 成功が一部にとどまった場合や不確実な場合は、依存する変更を停止し、シークレットを含めずに、検証済み、失敗、不明の各段階を報告します。リカバリーの前に、アーティファクト、ワークフロー、タグ、ブランチの実際の状態を確認します。公開をやみくもに再実行したり、リモートタグを上書きしたり、公開済みアーティファクトを削除したり、ロールバックしたと主張したりしてはなりません。既存の承認範囲内で、残っていることが確認された対応のみ再開します。

パスの完了

• 準備（変更履歴のみの場合を含む）： 選択した準備回答フォームに記入します。実際にレビューできるメモまたは差分、残っているチェック、後で行う公開承認ゲートを明示し、現時点で承認を求めないでください。
• 復旧／復旧レビュー： 選択した復旧回答フォームに番号付きセクションで記入し、返信する前に該当する処置をすべて確認します。
• リリース完了： リリースバージョン、コミット／タグ、検証、成果物の読み戻し、次の開発コミット、条件付きの GitHub Release URL を報告します。該当するすべてのチェックに合格した場合に限り、完了を宣言してください。

準備状況のレビューまたはブロッカーの場合は、より限定的な結果と残りのゲートを明示してください。認証情報の内容や機密性の高いコマンド出力をそのまま開示しないでください。