PRからの自動リリース
各リポジトリはPR内で変更内容と patch / minor / major を宣言します。main へのマージ後、そのコミットを検証し、GitHub Releaseを作成します。公式ライブラリはレジストリへの公開まで同じ処理で進みます。
PRを準備する
.release/change.example.json を作業用JSONへコピーして、変更内容を記入します。
{
"bump": "patch",
"summary": "範囲外の入力を保存前に拒否する",
"added": [],
"changed": [],
"fixed": ["範囲外の入力で状態が更新される問題を修正"],
"removed": [],
"breaking": false,
"migration": "依存を新しい完全一致バージョンへ更新し、既存のテストを実行する。"
}
dicks release prepare change.json
このコマンドは package.json、存在する場合のnpm lock、CHANGELOG.md、.release/notes/<version>.json を更新します。生成したファイルを実装・テストと一緒にPRへ含めます。migration は変更不要の場合も、その旨と確認手順を記載してください。
PRの検証では、ベースブランチのバージョンから正しく増加していること、変更の記録とパッケージ・changelogが一致することを確認します。1.0以降の破壊的変更はmajor、0.xの破壊的変更はminorまたはmajorが必要です。
PRタイトルとコミットメッセージは 8 = D ~ とASCII空白だけを使います。変更の説明はPR本文と変更記録へ書きます。各リポジトリはsquash mergeを使い、PRタイトルをマージコミットの件名にします。
マージ後の順序
- マージされたコミットをチェックアウトし、リポジトリ固有の検証を再実行する。
- ソース、変更記録、SHA-256チェックサムを作成する。
- GitHubのdraft releaseへ成果物をアップロードする。
- ライブラリの場合、同じバージョン・同じ内容をレジストリへ公開して読み戻す。
- GitHub Releaseを公開する。
main への直接pushではリリースしません。アプリケーションの本番配備、DB migration、既存の利用側の依存更新も行いません。レジストリへの公開と、利用側のlock更新は別の操作です。
途中で失敗した場合
draftは未公開のまま残します。修復後、Releaseワークフローを同じコミットで再実行できます。同じタグ・同じ成果物・同じレジストリ内容は再利用し、内容が違えば停止します。既存タグを別コミットへ付け替えたり、公開済みバージョンを上書きしたりしません。
手動実行の dry_run は既定で有効です。成果物を確認してから、同じコミットで実行してください。
公開用認証
13個の公式ライブラリには、それぞれ独立した DICKS_REGISTRY_TOKEN を登録しています。有効期間は365日、現在のレジストリが提供する権限単位は @dicks 名前空間への公開です。パッケージ単位の権限ではありません。期限前の更新、問題発生時の失効と再発行は運用者が行います。
認証値は公開ステップだけへ渡します。ソースアーカイブへローカルの未追跡ファイルや認証値を含めません。共有ワークフローとツールはコミットで固定します。
互換性と制限
この基盤の導入だけでは新バージョンの公開を意味しません。GitHub Releaseとレジストリの完全一致バージョンを確認してください。タグ・成果物・レジストリの内容が一致しない失敗は、再実行で無理に修復せず原因を調査します。