プルリクエストのプレビュー削除は、コマンド 1 つで済む作業に見えます。しかし、 Capgo注意点が 1 つあります。プレビューを削除する前にアクティブなプレビューから離れ、その後 ID で bundle を削除する必要があります。制限付きの API key、プレビューの検索、リセット処理、bundle の削除、CI 自動化を使った安全なクリーンアップフローを構築します。
目次
- ステップ 1: プレビューのクリーンアップ用に制限付きの Capgo API キーを作成する
- ステップ 2: プルリクエストのプレビューとその Bundle ID を特定する
- ステップ3: クリーンアップ前にアクティブなプレビューから切り替える
- ステップ4: API キーでIDを指定してプレビューBundleを削除
- ステップ 5: プルリクエストのクローズ時にクリーンアップを自動化
- ステップ 6: クリーンアップの検証とロールアウトの誤削除防止
- よくある質問
- まとめ
ステップ 1: プレビューのクリーンアップ用に制限付きの Capgo API キーを作成する
Capgo のプルリクエストプレビューのクリーンアップフローの最初のステップは、CIジョブに必要な作業だけを実行できるキーを作成することです。
組織全体のキーをプルリクエストのワークフローに入れないでください。プルリクエストはまだ信頼されていないブランチから来る可能性があります。また、失敗した実行時にワークフローがコマンドや環境変数の値を出力することもあります。権限を絞ったキーなら、そうなった場合の被害を抑えられます。
Capgo では、プレビュー作業にはまず App Preview キーを使用してください。キーは、ジョブが管理するアプリまたはプレビュースコープに紐づけてください。チームでロールベースのアクセス制御を使っている場合は、組織全体へのアクセスを付与するのではなく、キーを選択したアプリに限定してください。Capgo は、これらのプレビューキーの選択肢をドキュメントで説明しています。 Web アプリワークフロー向けの API キー設定.
シークレットは CI プロバイダーの暗号化されたシークレットストアに保存してください。何をするかがわかる名前を付けてください。例えばCAPGO_PREVIEW_CLEANUP_KEYなどです。ワークフローファイル、シェルスクリプト、プルリクエストのコメント、生成されたログに置かないでください。
キーは環境変数でクリーンアッププロセスに渡してください。変数がない場合は、スクリプトが失敗するようにしてください。サイレントフォールバックは危険です。クリーンアップジョブが認証なしのリクエストになったり、開発者がコマンドラインにキーを貼り付けたくなったりするからです。
if [ -z "$CAPGO_PREVIEW_CLEANUP_KEY" ]; then echo "Missing preview cleanup key" exit 1
fiこのキーは、本番バンドルを公開するキーとは分けてください。公開ジョブはリリースをアップロードする必要があるかもしれませんが、クリーンアップジョブはプレビューリソースを削除するだけで十分です。キーを分けるとレビューしやすくなり、削除操作が本番チャネルに届く可能性を減らせます。
可能な限り、保護された環境で同じシークレットを使ってください。ジョブが共有チャネルに触れる前に承認を必須にしてください。通常のプルリクエストプレビューでは、ジョブは一時チャネルだけで動作すべきです。
重要なポイント: 専用の App Preview キーを使い、アプリスコープを限定し、暗号化された CI シークレットに保管してください。
次に進む前に、無害な読み取り操作でキーをテストしてください。ジョブが対象のアプリを参照できる一方で、無関係なアプリや本番ワークフローにはアクセスできないことを確認します。クリーンアップの正確なリクエスト内容は完全には公開されていないため、最初のテストは小規模に留め、削除呼び出しを追加する前に SDK または Capgo のサポートガイダンスを確認してください。
ステップ 2: プルリクエストのプレビューとその Bundle ID を特定する
Capgo のプルリクエストプレビュークリーンアップ API キーは、ジョブがどのプレビューとバンドルIDを所有しているかを把握している場合にのみ役立ちます。
プレビューチャネルには安定した命名規則を使ってください。よくあるのはリポジトリ名とプルリクエスト番号の組み合わせです。重要なのは一貫性です。クリーンアップジョブは、プルリクエストがクローズされた後に同じ識別子を再構築できる必要があります。
プレビュー作成時にプレビューチャネル名を保存してください。ワークフローの出力、プルリクエストチェック、ジョブメタデータの一部に置けます。ダッシュボードで人が変更する可能性のある表示名に依存しないでください。
次に、そのプレビューに関連するbundleを一覧表示します。CapgoのDelete Bundleアクションにはbundle IDが必要です。ドキュメントでは、削除前に利用可能なすべてのbundle IDを取得するため、一覧取得の呼び出しを行うよう示されています。このリストをsource of truthとして扱ってください。ファイル名、コミットハッシュ、ブランチ名からIDを推測しないでください。
取得したレコードを、プレビューチャネルやワークフローが管理する別の値でフィルタリングします。一致した各項目のbundle IDを正確に保持してください。リストが空なら、クリーンアップ完了としてマークします。ワークフローがプレビューの存在を期待している場合を除き、空の結果は失敗ではありません。
また、各プレビューを生成したコミットSHAも記録してください。これにより、削除前に2つ目のチェックができます。チャネル名は一致してもコミットが異なる場合は、停止してレビューを依頼してください。この少しの停止で、古いクリーンアップジョブの実行中に新しいプレビューがビルドされる競合を防げます。
パブリッシュジョブが実行中の間は削除しないでください。プレビュービルドとクリーンアップワークフローの間に依存関係を追加するか、プルリクエスト番号をキーとするロックを使用してください。クリーンアップジョブは、closeイベントと保留中のプレビューアップロードの両方が終了した後にのみ開始されるべきです。
Capgoの公開APIは、認証付きHTTPリクエストを通じてチャネルやバンドルなどのリソースをカバーしますが、クリーンアップアクションはプロジェクト内で慎重な検証が必要です。 Capgo公開API概要 ラッパーを書く前に、現在のリソースモデルを確認するには最適な場所です。
この時点で、プレビュー識別子、正確なバンドルIDのリスト、および各レコードに関連付けられたコミットSHAを持っているはずです。これらの値が欠けている場合は、ここで停止してください。所有権チェックなしのクリーンアップは推測に過ぎません。
ステップ3: クリーンアップ前にアクティブなプレビューから切り替える
アクティブなプレビューは、アプリがそのプレビューから切り替えるか、またはresetPreviewを呼び出すまで削除できません。これが Capgo のプルリクエストプレビューのクリーンアップフローで重要なポイントです。
アクティブなプレビューは、アプリが現在選択しているバージョンだと考えてください。サーバー側のレコードを先に削除すると、アプリが存在しないものを指したままになります。Capgo はこの状態変更をブロックするため、クリーンアップジョブではプレビューを削除する前にアプリのプレビュー状態をリセットする必要があります。
まず、プレビューがまだアクティブかどうかを確認します。アクティブな場合は、アプリを安全なチャネルに移動するか、updater のリセットアクションを使用します。適切な選択はテストアプリの構成によって異なります。使い捨てのテストアプリは通常のデフォルトチャネルに戻せます。共有テストアプリの場合は、代わりに専用のステージングチャネルが必要になることがあります。
使用するresetPreviewプレビュー状態を直接クリアする必要がある場合に使用します。この呼び出しは、プレビューを作成した同じプルリクエストとアプリに紐付けてください。クリーンアップスクリプトは、チャネル名が偶然一致したという理由だけで本番デバイスや共有リリースチャネルをリセットするべきではありません。
ここで役立つ順序ルールがあります：
- プルリクエストがクローズされていることを確認します。
- プレビューのアップロードが実行中でないことを確認します。
- アクティブなプレビューから切り替えるか、次を呼び出します：
resetPreview. - その状態変更が完了するのを待ちます。
- その後でのみ Delete Preview を呼び出します。
リセットリクエストに対するHTTPレスポンスの成功は、すべてのデバイスでアプリの状態が変更されたことを保証するものではありません。デバイスは後でアップデートを確認する可能性があります。API のレスポンスに従ってプレビュー割り当てがクリアされた時点で、サーバー側のクリーンアップを進めることができますが、デバイスの挙動とリソースの削除は分離して管理してください。
Capgo はチャネルベースのロールアウト制御をサポートしており、この分離をより明確に理解しやすくします。チャネルは、アプリがどのアップデートストリームに従うべきかを指定する名前付きパスです。プレビューチャネルは、本番環境のデバイスで使用されるチャネルと同じにしてはいけません。
より厳密な境界が必要なチームには、ドキュメントに記載されている プレビュー自動化のための Capgo チャンネルワークフロー. これは一時的なチャンネルパターンを説明するもので、クリーンアップジョブが共有のデフォルトチャンネルに触れないようにするのに役立ちます。
オープンソースのアップデーターのドキュメントには、削除制限についても記載されています。アクティブなプレビューは、先に別のチャンネルへ切り替えるかリセットする必要があります。ソースは Capgo Capacitor アップデーターのリポジトリで確認できます。ダッシュボードの文言だけではCIの判断を下すには簡潔すぎる場合に、このソースが役立ちます。
プロのヒント: リセットはログに残る別ステップにしてください。Delete Preview が失敗した場合、ログでプレビューがまだアクティブだったのか、削除リクエストに別の問題があったのかを確認できるようにします。
アクティブ状態が解除されたら、プレビューレコードは削除できる状態になります。リセットと削除を1行の分かりにくいシェルコマンドにまとめないでください。2つの明確なコマンドに分ければ、リトライしやすく、監査もはるかに簡単になります。
ステップ4: API キーでIDを指定してプレビューBundleを削除
アクティブなプレビューをリセットした後、各プレビューBundleをその正確なIDで削除します。ここでは Capgo クリーンアップキーが、プルリクエストによって残されたストレージオブジェクトを削除します。
ステップ2のBundleリストから始めます。一致する各IDについて、Capgo SDK またはアカウントで利用可能な現在の公開 API メソッド経由で、Delete Bundleアクションを呼び出します。
SDK のメソッドシグネチャを調べるか、Capgo サポートに現在のリクエスト形式を確認してください。確認できたら、メソッドとレスポンス形式をチームの内部ランブックに記録してください。ランブックには、API のバージョン、必須の識別子、リトライロジックで処理できるエラーコードを含めてください。
スクリプトで dry-run モードを使ってください。削除リクエストを送らずに、プレビューチャネルと削除対象の bundle ID を出力します。このモードを、クローズ済みの複数の pull request に対して実行してください。本番チャネルが除外され、空のリストがワイルドカードとして扱われないことを確認してください。
安全な削除ループには3つのゲートがあります:
- bundle ID がない、または形式が不正な場合は拒否する。
- pull request のプレビューとチャネルが一致しない bundle は拒否する。
- 所有権チェックが通った場合にのみ削除する。
次に、レスポンスを種類ごとに処理します。削除成功は完了として記録できます。Not Found レスポンスは、以前のリトライでリソースが削除済みとわかっている場合は、すでにクリーンとして扱えます。権限エラーはジョブを失敗させ、オーナーに通知すべきです。レート制限では、上限付きの遅延で一時停止してリトライします。
すべてのエラーをリトライしないでください。不正な ID は3回試しても有効になりません。認可エラーは通常、キーのスコープが間違っていることを意味します。一時的な失敗だけをリトライし、クリーンアップジョブがスタックして CI キューを消費しないよう、最大実行時間を設定してください。
Bundleの削除はpreviewの削除とは別です。preview channelを削除しても、すべてのbundleがなくなったことを自動的に証明するわけではありません。ジョブは各IDの結果を保持し、APIが対応しているなら最後に list リクエストを送ってください。bundleが残っている場合は、黙って成功と報告せず、そのIDを報告して停止してください。
削除ログにはsecretを含めないでください。プルリクエスト番号、preview名、bundle ID、リクエスト結果、タイムスタンプをログに記録するのは問題ありません。APIキー、Authorizationヘッダー、またはそれらを含む可能性のあるリクエストオブジェクト全体は絶対にログに記録しないでください。
この方法なら、ログを新たな認証情報の漏えい経路にせず、有用な監査トレイルを残せます。また、失敗したクリーンアップも、次回実行時に存在しないと確認済みのレコードをスキップできるため、簡単に再開できます。
ステップ 5: プルリクエストのクローズ時にクリーンアップを自動化
プルリクエストのクローズイベントでクリーンアップジョブを実行しますが、遅れて実行されたビルドが新しいpreviewを削除しないよう、チェックを追加してください。
ワークフローは、イベントペイロードからリポジトリとプルリクエスト番号を受け取るようにします。それらの値からpreview channel名を組み立て直してください。プルリクエストのコメントや信頼できないブランチ変数から渡されたchannel名は受け入れないでください。
ジョブの流れは次のとおりです:
- 暗号化されたsecretから、権限を絞ったクリーンアップキーを読み込む。
- イベントがクローズされたプルリクエストであることを確認する。
- previewが想定どおりのリポジトリとアプリに属しているか確認する。
- 実行中のpreviewデプロイが完了するまで待機する。
- previewから切り替えるか、次を呼び出す
resetPreview. - そのプレビューのbundle IDを一覧表示します。
- 検証済みのbundleをそれぞれ削除します。
- プレビューレコードを削除します。
- ワークフローのサマリーに結果を簡潔に書き込みます。
順序が重要です。先に削除すると、アクティブなプレビュールールがリクエストをブロックする可能性があります。リスト取得をスキップすると、どのバンドルIDがまだ存在しているか把握できない場合があります。推測した名前で削除すると、誤ったリソースを操作するリスクがあります。
プルリクエスト番号をキーにした並行性ルールを使用してください。クローズイベントと再ビルドイベントがほぼ同時に到着した場合、古いクリーンアップジョブが新しいデプロイメントと競合してはいけません。不要なクリーンアップ実行をキャンセルするか、デプロイメントロックが解放されるまでジョブを待機させてください。
CapgoのワンコマンドCLIワークフローにより、ビルドやリリース作業周辺のカスタムシェル呼び出しの数を削減できます。コマンド名とサポートされている操作については、 Capgo CLIコマンドのドキュメントを参照してください。検証済みのコマンドが得られる場合はCLIを使用してください。クリーンアップアクションで直接のリクエストが必要な場合は、SDKまたはパブリックなAPIを使用してください。
すべてのpushで実行されるワークフローにクリーンアップを配置しないでください。pushジョブが、まだテスト中のプレビューを削除してしまう可能性があります。通常のクリーンアップには、closeイベントが適切なトリガーです。ジョブが失敗した場合の復旧用に、手動のワークフローディスパッチを追加してください。
保持期間のフォールバックも設定しておきましょう。クローズイベントを見逃した場合でも、スケジュールされたジョブがチームの許可するテスト期間を過ぎたプレビューを特定できます。このジョブには、通常のクローズフックよりも厳格なセーフガードが必要です。所有者が明確で、期限切れのタイムスタンプを持つプレビューのみを対象にしてください。
GitHub Actionsでは、権限を最小限に絞り、クリーンアップステップに必要な値のみを渡すようにします。Capgoの現在のGitHub Actions連携ドキュメントでは、トークンの保存場所や、ワークフローがCapgoにどのように接続するかを説明しています。
これで、クローズに反応し、競合するジョブを待ち、アクティブ状態をリセットし、IDを一覧化して、一致したbundleだけを削除する自動化フローができました。クリーンアップをやみくもな一括削除にせず、日々の開発に十分な速さです。
ステップ 6: クリーンアップの検証とロールアウトの誤削除防止
検証を行うことで、Capgoのプルリクエストプレビューのクリーンアップループが完結します。安全なリリースプロセスには、削除レスポンスだけでは不十分です。
クリーンアップジョブの実行後、プレビューチャンネルを再度確認してください。アクティブなプレビューとして表示されていないことを確認します。次に、同じアプリとフィルターでbundleリストを確認します。対象のbundle IDが消え、本番用のbundleが残っていれば成功です。
以下の値をジョブのサマリーに保存してください：
- リポジトリとプルリクエスト番号。
- プレビューチャンネル名。
- 所有者チェックに使用したコミットSHA。
- 検出されたbundle ID。
- 削除されたbundle ID。
- エラーを返した ID。
明確なステータスを使用してください。「Cleaned」は、検証済みのターゲットがすべて削除されたことを意味します。「Already clean」は、この実行前にリソースが存在しなかったことを意味します。「Needs review」は、1つ以上のチェックが失敗したことを意味します。部分的な削除を成功としてラベル付けしないでください。
code に本番環境用のガードを追加してください。デフォルトチャンネルやリリースチャンネルなどのチャンネル名を拒否してください。また、メタデータがプレビューアプリと一致しない bundle も拒否してください。ガードは fail closed で動作させてください。スクリプトがターゲットを確実に特定できない場合は、処理を停止してください。
ロールバックとクリーンアップは分けて考えてください。ロールバックはデバイスが受信する bundle を変更するものであり、クリーンアップは古いプレビューリソースを削除するものです。プルリクエストのクローズ後にバグが見つかった場合、調査のために bundle が必要になることがあります。マージ後にデバッグを行うことが多いチームであれば、イベント発生時に即削除するのではなく、短い保持期間を設定してください。
よくある3つの失敗パターンに注意してください：
- アクティブなプレビューエラー： Delete Preview を再試行する前に、リセットするか別の画面に切り替えてください。
- Bundle ID が見つかりません： 推測するのではなく、再度 list アクションを実行してください。
- 権限エラー： キーのスコープを確認し、必要に応じて新しいキーを発行してください。
セキュリティポリシーに基づいたスケジュールでクリーンアップ用のキーをローテーションしてください。ログやコミットにキーが露出した場合は、直ちにローテーションしてください。露出により即時の無効化が必要な場合を除き、新しいキーをテストしてから古いキーを失効させてください。
クリーンアップに関するドキュメントの不足は、セキュリティレビューで言及しておくべき点です。SDK と検証済みの Capgo ガイダンスを実装の根拠として扱い、独自のリクエストコントラクトはバージョン管理してください。
重要なポイント: 削除後にプレビューと bundle リストを確認し、code では本番ターゲットをブロックしてください。部分的なクリーンアップは失敗として報告してください。
1つのコマンドが役立つのは、ガードレールが明確なときだけです。プレビューを追跡し、予測可能なチャンネル名を採用してください。リリース変更のロールバックは別途行ってください。その上で、クリーンアップジョブがライブトラフィックに触れずに小さな役割を果たすようにしてください。
よくある質問
アクティブな Capgo プルリクエストプレビューを削除できますか？
いいえ。アクティブなプレビューは先に別のものへ切り替えるか、API を呼び出す必要がありますresetPreview。アクティブ状態が解消したら、Delete Preview を実行してください。このルールは、CI で Capgo プルリクエストプレビューのクリーンアップ用 API キーを設定する際に、覚えておくべき主なポイントです。
Capgo のプレビューをクリーンアップするには、bundle ID が必要ですか？
はい。Capgo の Delete Bundle アクションには bundle ID が必要なので、削除する前に利用可能な bundle を一覧表示してください。各 ID をプレビューチャンネルと照合し、削除リクエストを送信する前に commit してください。ブランチ名から ID を組み立てたり、プレビューを削除すればすべての bundle も削除されると決めつけたりしないでください。
プレビューのクリーンアップに、CI はどの種類の API キーを使うべきですか？
プレビューのクリーンアップには、CIプロバイダーの暗号化されたシークレットストアに保存した制限付きのApp Preview keyを使用してください。キーは必要なアプリまたはスコープだけに制限します。本番アップデートの公開に使うキーとは分けてください。これにより、Capgo のクリーンアップジョブはレビューしやすくなり、ローテーションも安全になります。
プルリクエストがクローズされたときにクリーンアップを自動化できますか？
はい。クローズされたプルリクエストのイベントでクリーンアップをトリガーし、プレビューをリセットする前に実行中のデプロイジョブの完了を待機します。bundle IDを一覧表示し、検証済みの一致するbundleを削除して結果を確認します。遅れて実行されるビルドがクリーンアップジョブと競合しないよう、同時実行制御を追加してください。
Capgo のクリーンアップリクエストが失敗する原因は何ですか？
主な原因は、プレビューがアクティブであること、bundle IDがないこと、またはキーに必要なスコープがないことです。まずプレビューをリセットし、list呼び出しを繰り返して、キーの権限を確認してください。リクエストの詳細は API や SDK のバージョンによって異なる場合があるため、スクリプトを変更する前に現在のメソッドとパラメータを確認してください。
まとめ
専用のプレビューキーとともに Capgo を使用し、厳格なクリーンアップ順序を守ってください。アクティブなプレビューをリセットし、そのbundle IDを一覧表示し、検証済みbundleを削除してから、プレビューを削除します。まずクローズ済みのプルリクエスト1件でdry runを行い、現在の SDK でリクエストの形式を確認し、自動クリーンアップを有効にする前にproduction channel用のガードを追加してください。
