この公開ワークフローは、ZimaOS ホームサーバーと Homelab が利用できるように、Docker App Store を静的ホスティングへ配信します。
このページでは、タグ付きリリースの公開に使用する .github/workflows/release-store.yml を説明します。
目的
リリース準備が整ったビルド出力を公開配信先へデプロイします。
トリガー
v*に一致するタグの push- 手動の
workflow_dispatch
手動実行では purge_only を指定すると、ストアを再ビルドまたは再デプロイせずに、直近の gh-pages デプロイで変更されたファイルを更新できます。
主な段階
- リポジトリのソースをチェックアウトします。
- ビルドキャッシュを復元します。
- v2 プロトコルの
dist/をビルドします。 - 従来の v1 zip 出力をビルドします。
- リリースバンドルを作成します。
- リリース成果物とレポートをアップロードします。
- ビルドキャッシュを保存します。
- リリース summary を書き込みます。
dist/をgh-pagesにデプロイします。- デプロイで変更されたファイルを収集し、jsDelivr のキャッシュエントリを更新します。
- バンドルを添付した GitHub Release を作成します。
キャッシュ更新は gh-pages へのデプロイ後に実行されます。前後の gh-pages リビジョンを比較し、ストアのエントリポイントを必ず含め、パスをバッチに分けて jsDelivr へ送信します。更新スクリプトは purge 結果をポーリングし、一時的な HTTP エラーを再試行します。jsDelivr がレート制限または失敗を報告した場合は明示的に失敗します。その後、配信元と CDN 応答のハッシュを比較するため、purge 要求が受理されただけの状態を、キャッシュ更新完了と誤認しません。
公開される出力
現在、このワークフローは次を公開または添付します。
- v2 プロトコル用の
gh-pages静的dist/出力 - v1 互換用の
main.zip - ダウンロード用の zip リリースバンドル
- トラブルシューティング用の JSON ビルドレポート
重要な理由
サードパーティストアのリポジトリを公式公開手順に合わせる場合、このワークフローが最も近いリファレンスです。
公式リポジトリが次をどのように分けているかを示します。
- ビルド時の成果物
- 公開時のデプロイ
- 手動ダウンロード用のリリース添付ファイル
関連するビルドワークフロー
公開を行わないビルドワークフローは、ビルドワークフローで説明しています。
外部リポジトリを設計する場合は、公式アクションの再利用で推奨方法を確認してください。