Release Checklist

KonomiTV の新バージョンをリリースする前に、ユーザーと一緒に確認事項を潰していくためのチェックリスト。 リリース頻度が数ヶ月おきのため手順を忘れがちなので、このスキルで毎回漏れなく進められるようにする。

リリースフローの全体像

[手動] リリース前の確認・準備 (このスキルのスコープ)
  ↓
[手動] Dockerfile のリリース準備コミット
  ↓
[手動] GitHub Actions「Create Release Commit」を workflow_dispatch で実行
  ↓ (以降は自動)
[自動] バージョン番号の一括更新・クライアントビルド・Release コミット作成
[自動] release ブランチ更新 → インストーラー & サードパーティビルド
[自動] タグ作成 → GitHub Release 作成 (generateReleaseNotes: true)
[自動] Docker イメージのビルド & 公開
  ↓
[手動] GitHub Release のリリースノートを編集 (generate-release-notes スキルの出力をマージ)

チェックリスト

以下のチェック項目を上から順にユーザーと確認していく。 エージェントが自動で確認できる項目はエージェントが実行し、ユーザーへの確認が必要な項目はユーザーに質問する。

Phase 1: コードの最終確認

• master ブランチが最新か
  • git status と git log --oneline -5 で確認する
  • 未 push のコミットがないか、意図しない変更が残っていないか
• クライアントの lint / 型チェックが通るか
  • client/ で yarn lint と yarn typecheck を実行する
  • クライアントのビルド自体は Create Release Commit ワークフロー内で自動実行されるため、手元での yarn build は不要
• サーバー側の lint / 型チェックが通るか
  • server/ で poetry run task lint を実行する

Phase 2: サードパーティライブラリの確認

• サードパーティライブラリのバージョンが最新か
  • .github/workflows/build_thirdparty.yaml に定義されている各ライブラリのバージョンを確認する
  • 特に QSVEncC / NVEncC / VCEEncC / FFmpeg / rkmppenc は頻繁に更新されるので、gh release list で各リポジトリの最新リリースを取得し、現在のバージョンと比較する
    • gh release list --repo rigaya/QSVEnc --limit 1
    • gh release list --repo rigaya/NVEnc --limit 1
    • gh release list --repo rigaya/VCEEnc --limit 1
    • gh release list --repo rigaya/rkmppenc --limit 1
    • FFmpeg は BtbN/FFmpeg-Builds のリリースを確認する
  • 差分がある場合は「現在 X.XX、最新 X.XX」のように比較結果をユーザーに報告し、更新するか判断を仰ぐ
  • 更新が必要な場合は、ユーザーが build_thirdparty.yaml のバージョンを更新してコミットする
• 開発版 Dockerfile の thirdparty URL が最新の CI ランの成果物を指しているか
  • Dockerfile 内の nightly.link URL の actions/runs/XXXXXXX が、最新の build_thirdparty ワークフロー実行の run ID と一致しているか確認する
  • サードパーティライブラリのバージョンを更新した場合、CI が完了した後にこの URL も更新する必要がある

Phase 3: Dockerfile のリリース準備

• Dockerfile を「リリース版用」に切り替える

  • 以下の変更を行い、Update: [Dockerfile] リリース準備 としてコミットする
  • ただし、この時点ではまだ push しない。 リリース版 URL のバージョン番号は Create Release Commit ワークフローが自動で更新するため、前回リリースのバージョン番号のままで構わない

  変更内容:

  # 「リリース版用」の行のコメントを外す
  RUN aria2c -x10 https://github.com/tsukumijima/KonomiTV/releases/download/v(前回バージョン)/thirdparty-linux.tar.xz
  RUN tar xvf thirdparty-linux.tar.xz
  
  # 「開発版用」の行をコメントアウトする
  # RUN aria2c -x10 https://nightly.link/tsukumijima/KonomiTV/actions/runs/XXXXXXX/thirdparty-linux.tar.xz.zip
  # RUN unzip thirdparty-linux.tar.xz.zip && tar xvf thirdparty-linux.tar.xz
  

Phase 4: リリースノートの下書き生成

• generate-release-notes スキルを実行して下書きを生成する
  • /tmp/konomi-tv-release-notes-draft.md に出力される
  • ユーザーがこの下書きをベースに加筆修正し、最終版を用意する
  • リリースノートの最終版は GitHub Release 作成後に編集画面で反映する

Phase 5: リリースの実行

• Dockerfile のリリース準備コミットを push する
  • Phase 3 で作成したコミットを git push する
• GitHub Actions「Create Release Commit」を実行する
  • ユーザーに依頼: GitHub の Actions タブから Create Release Commit ワークフローを手動実行してもらう
  • バージョン番号を入力する (例: 0.14.0、v は付けない)
  • このワークフローが以下を自動で行う:
    • 各ファイルのバージョン番号を一括更新
    • クライアントのビルド
    • Release: version X.X.X コミットの作成と push
    • release ブランチの更新
• Publish Release ワークフローの完了を待つ
  • release ブランチの更新をトリガーに、インストーラー・サードパーティライブラリのビルドとリリース作成が自動実行される
  • 完了まで30分〜1時間程度かかる

Phase 6: リリース後の作業

• GitHub Release のリリースノートを編集する
  • GitHub が generateReleaseNotes: true で自動生成した内容 (Dependabot PR 一覧・外部 PR 一覧・New Contributors) に、Phase 4 で準備した下書きをマージする
  • スクリーンショットや動画の追加、文面の最終調整を行う
• Docker イメージが正常に公開されたか確認する
  • Publish Docker Image ワークフローの実行結果を確認する
• Dockerfile を「開発版用」に戻す
  • Phase 3 の逆の変更を行う
  • thirdparty の nightly.link URL は最新リリースの build_thirdparty ワークフローの run ID に更新する
  • Update: [Dockerfile] 開発版用サードパーティーライブラリを更新 としてコミット & push する
• リリースの告知
  • ユーザーに確認:「Twitter (X) での告知は行いますか？」

エージェントが自動実行できる項目

以下はエージェントが自律的に実行してよい項目:

• git status / git log による状態確認
• yarn lint / yarn typecheck によるクライアント側 lint / 型チェック確認
• poetry run task lint によるサーバー側 lint 確認
• Dockerfile の diff 確認
• .github/workflows/build_thirdparty.yaml のバージョン確認
• gh release list で各サードパーティライブラリの最新バージョンとの比較

エージェントがユーザーに確認すべき項目

以下は必ずユーザーの判断・操作が必要:

• サードパーティライブラリの更新判断
• GitHub Actions ワークフローの手動実行
• リリースノートの最終承認
• リリース告知の判断