Capgo プルリクエストプレビュークリーンアップ API キー

プルリクエストプレビューの削除は、一コマンドの仕事のように見えますが Capgoしかし、1 つのハズレがあります: 有効なプレビューから切り離す必要があります。その後、ID でバンドルを削除する必要があります。安全なクリーンアップフローを構築するには、制限された API キー、プレビューの検索、リセットの処理、バンドルの削除、および CI の自動化が必要です。

ステップ 1: プレビュークリーンアップ用に制限された Capgo API キーを作成する
ステップ 2: プルリクエストプレビューとそのバンドル ID を特定する
ステップ 3: クリーンアップ前に有効なプレビューから切り離す
Step 4: Delete Preview Bundles by ID With the API Key
ステップ 5: プルリクエストがクローズされたときに自動でクリーンアップする
ステップ 6: クリーンアップを検証し、誤って削除されるロールアウトを防ぐ
FAQ
結論

ステップ 1: プレビュークリーンアップ用に制限された Capgo API キーを作成する

Capgo プルリクエストプレビュークリーンアップフローの最初のステップは、CI ジョブが必要とする作業のみを行うことができるキーの作成です。

プルリクエストワークフローに広範な組織キーを入れないでください。プルリクエストは、まだ信頼を得ていないブランチから来る可能性があります。ワークフローは、実行に失敗したときにコマンドまたは環境値を出力する可能性があります。狭いキーは、起こり得る損害を制限します。

Capgo で、プレビュー作業用のアプリプレビューキーから始めます。キーは、ジョブが管理するアプリまたはプレビュースコープに紐付けされている必要があります。チームがロールベースのアクセス制御を使用している場合、キーを選択したアプリに制限するのではなく、組織全体にアクセスを許可するのではなく、キーを制限する必要があります。 Capgo は、プレビューキーに関する選択をドキュメント化しています。 API キー設定.

シークレットを CI プロバイダーの暗号化されたシークレットストアに保存します。シークレットに名前を付け、シークレットが何をするかを示すようにします。CAPGO_PREVIEW_CLEANUP_KEYシークレットをワークフローファイル、シェルスクリプト、プルリクエストコメント、または生成されたログに置かないでください。

環境変数を通じてキーをクリーンアッププロセスに渡します。スクリプトは、変数が欠如している場合に失敗するようにする必要があります。静的なフォールバックは危険です。なぜなら、クリーンアップジョブが認証なしでリクエストに変わり、または開発者がコマンドラインにキーを貼り付けるよう誘導されるからです。

if [ -z "$CAPGO_PREVIEW_CLEANUP_KEY" ]; then echo "Missing preview cleanup key" exit 1
fi

本番パッケージを公開するために使用するキーとは別に、このキーを保持してください。パブリッシュジョブはリリースをアップロードする必要があるかもしれませんが、クリーンアップジョブはプレビュー資源のみを削除する必要があります。別々のキーを使用すると、削除アクションが本番チャネルに到達する可能性を減らし、レビューが容易になります。

可能な限り保護された環境で同じシークレットを使用してください。ジョブが共有チャネルに触れることを許可する前に、承認を要求してください。通常のプルリクエストプレビューの場合、ジョブは一時チャネルにのみ作用し、他のものには作用しないようにする必要があります。

重要なポイント: プレビュー用に専用のアプリキーを使用し、そのアプリのスコープを制限し、CIシークレットに暗号化しておく必要があります。

最初のテストを実行する前に、キーを無害な読み取りアクションでテストしてください。ジョブが意図したアプリを確認でき、関連するアプリや本番ワークフローにアクセスできないことを確認してください。クリーンアップの詳細は完全に公開されていないため、最初のテストを小さくし、SDK または Capgo のサポートガイドを参照する前に、削除コールを追加しないようにしてください。

ステップ 2: プルリクエストプレビューとそのバンドル ID を特定する

The Capgo pull request preview cleanup API key is useful only when your job knows which preview and bundle IDs it owns.

プレビューチャンネルの命名規則を安定させる。リポジトリ名とプルリクエスト番号を組み合わせるパターンはよく使われる。重要なのは一貫性だ。プルリクエストが閉じた後も、クリーンアップジョブは同じ識別子を再構築する必要がある。

プレビューが作成されたときにプレビューチャンネル名を保存する。ワークフロー出力、プルリクエストチェック、またはジョブメタデータの小さな部分に保存する。表示名は、ダッシュボードで人が変更する可能性があるため、依存しないようにする。

次に、プレビューに紐付けられたバンドルの一覧を表示する。Capgoの「バンドル削除」アクションにはバンドル IDが必要。ソースドキュメントは、削除する前にすべてのバンドル IDを取得するリスト呼び出しを指示している。リストを真実の元とする。ファイル名、コミットハッシュ、ブランチ名から ID を推測しない。

返されたレコードをプレビューチャンネルまたはワークフローが制御する別の値でフィルタリングする。次に、各一致のバンドル IDを正確に保持する。リストが空の場合、クリーンアップを完了としてマークする。空の結果は、ワークフローがプレビューの存在を期待していない限り、失敗とは見なさない。

また、各プレビューの生成したコミット SHA を記録する。2 つのチェックを実行するために役立つ。チャンネル名が一致するがコミットが一致しない場合、停止し、レビューを求める。小さな停止は、古いクリーンアップジョブが実行されている間に新しいプレビューが作成されている可能性を防ぐ。

プルリクエストプレビューチャンネルとバンドル ID のレビューは、Capgo クリーンアップ

まだ公開ジョブが実行中の場合、削除しないでください。プレビュービルドとクリーンアップワークフロー間の依存関係を追加するか、プルリクエスト番号に基づいてロックを使用してください。クリーンアップジョブは、クローズイベントが発生し、予定されていたプレビューアップロードが終了した後のみ実行されるべきです。

Capgoの公開APIは、チャンネルやバンドルなどのリソースを認証済みHTTP要求でカバーしていますが、クリーンアップアクションはプロジェクト内で慎重に検証する必要があります。 Capgoの公開API概要 __CAPGO_KEEP_0__の公開__CAPGO_KEEP_1__の概要

この時点で、プレビュー識別子、正確なバンドルIDのリスト、および各レコードに紐付けられたコミットSHAを持っているはずです。必要な値が欠けている場合はここで停止してください。所有権のチェックなしでクリーンアップすることは、推測に他なりません。

ステップ 3: アクティブプレビューから切り替えてクリーンアップ

アクティブプレビューは、アプリが切り替えてからまたは__CAPGO_KEEP_0__を呼び出すまで削除できません。これは__CAPGO_KEEP_0__のプルリクエストプレビュークリーンアップフローの重要な詳細です。resetPreviewCapgoのプルリクエストプレビュークリーンアップフロー

アクティブプレビューを削除することは、現在アプリが選択しているバージョンを指し示すことと同じです。サーバー側のレコードを削除すると、アプリは存在しないものを指し示すことになります。Capgoはその状態変化をブロックするので、クリーンアップジョブはアプリのプレビュー状態をリセットする必要があります。

最初は、プレビューがまだ有効かどうかを確認してください。有効の場合、安全なチャネルにアプリを移動するか、アップデートリセットアクションを使用します。どちらの選択肢が適切かは、テストアプリの設定に依存します。廃棄可能なテストアプリは、通常のデフォルトチャネルに戻すことができます。共有テストアプリには、専用のステージングチャネルが必要になる場合があります。

使用resetPreviewプレビュー状態を直接クリアする必要がある場合に使用します。プレビューを作成した同じプルリクエストとアプリとを紐付けしてください。クリーンアップスクリプトは、チャンネル名が一致するだけでは、生産環境のデバイスや共有リリースチャネルをリセットしてはなりません。

有用な並べ替えのルールがあります。

プルリクエストが閉じられていることを確認します。
プレビューのアップロードが実行されていないことを確認します。
アクティブなプレビューから切り替えます。もしくはresetPreview.
その状態の変更が完了するのを待ちます。
Delete Preview を呼び出すのは、上記のステップを実行した後のみです。

成功した HTTP 応答から、すべてのデバイスがすでに状態を変更したことを証明するものではありません。デバイスは、後で更新を確認する可能性があります。サーバーサイドのクリーンアップは、プレビューの割り当てが API 応答に従ってクリアされた後でも続行できますが、デバイスの動作とリソースの削除を別々に考慮してください。

Capgo は、チャンネルベースのロールアウト制御をサポートしており、これによりこの分離がより論理的に考慮できるようになります。チャンネルは、更新の流れを決定するためにアプリに名前を付ける名付けられたパスです。プレビューのチャンネルは、生産デバイスが使用するチャンネルと同じにすることはできません。

チームがより厳密な境界を必要とする場合は、ドキュメントされた Capgo チャネルワークフローによるプレビュー自動化 . これは、暫定チャネルパターンと共に、共有デフォルトチャネルからクリーンアップジョブを遠ざけるためのものです。

オープンソースのアップデーター文書には、削除制限も記載されています: アクティブなプレビューには、Switch Away または Reset を実行する必要があります。 Capgo Capacitor アップデーターリポジトリのソースを確認してください。そのソースは、ダッシュボードの表現が CI の決定に不十分な場合に役立ちます。

プロのヒント: リセットを別のログステップとして実行してください。 Delete Preview が失敗した場合、ログにはプレビューがまだアクティブだったか、削除要求に別の問題があったかを示すことが必要です。

アクティブ状態が消えたら、プレビューのレコードは削除のために準備が整いました。リセットと削除を 1 つのオパックシェルラインに組み合わせないでください。 2 つの明確なコマンドは、再実行が容易になり、監査も容易になります。

ステップ 4: プレビューバンドルを ID で削除するには、API キーを使用します。

アクティブなプレビューがリセットされた後、各プレビューバンドルをその精確な ID で削除します。これは、プルリクエストによって残されたストレージオブジェクトを削除する Capgo クリーンアップキーが使用されます。

ステップ 2 のバンドルリストから始めて、各一致する ID に対して、Capgo SDK または現在のパブリック API メソッドを使用して、Delete Bundle アクションを呼び出してください。

SDK メソッドのサインャーをインスペクトし、または Capgo サポートで現在のリクエストの形状を確認します。確認した後、チームの内部の実行本を更新し、メソッドとレスポンスのフォーマットを記録します。実行本には、API バージョン、必要な識別子、およびリトライロジックが処理できるエラーコードが含まれます。

スクリプトでドライランモードを使用します。ドライランモードでは、プレビューチャネルと削除しない bundle ID を表示し、削除要求を送信せずに実行します。複数のクローズドプルリクエストに対してドライランモードを実行し、生産チャネルを除外し、空のリストをワイルドカードとして扱わないことを確認します。

安全な削除ループには 3 つのゲートがあります。

不正または不正な bundle ID を拒否します。
プルリクエストプレビューと一致しない bundle のチャネルを拒否します。
所有権のチェックが通過した後のみ削除します。

次に、各レスポンスをタイプごとに処理します。成功した削除は完了として記録できます。存在しないレスポンスは、リソースが以前のリトライによって削除されたことがわかっている場合はすでにクリーンとして扱います。許可エラーはジョブを失敗させてオーナーに通知します。レート制限は停止し、最大延期でリトライします。

すべてのエラーをリトライしないでください。有効な ID には 3 回の試行後も変わりません。認証エラーは通常、キースコープが間違っていることを意味します。リトライするのは、トランスジットフェイルのみで、最大実行時間を設定して、CI キューを占有しないようにしてください。

バンドル削除はプレビュー削除とは別です。プレビューチャネルを削除しても、すべてのバンドルが削除されたことを保証するわけではありません。各 ID に対して結果を保持し、API がサポートする場合に、最終リスト要求を実行してください。残っているバンドルがあれば、ID を報告し、成功を静かに宣言するのではなく、停止してください。

削除ログからシークレットを除外してください。プルリクエスト番号、プレビュー名、バンドル ID、要求結果、タイムスタンプをログに記録するのは問題ありません。API キー、認証ヘッダー、またはフルリクエストオブジェクトを含む可能性があるため、API キーをログに記録しないでください。

そのアプローチは、ログが資格情報が漏洩する別の場所になるのを防ぎながら、有用なアクセストレイルを提供します。失敗したクリーンアップを簡単に再開できるように、次の実行はすでに欠落していることを確認したレコードをスキップできるようにします。

ステップ 5: プルリクエストがクローズされたときにクリーンアップを自動化する

プルリクエストクローズイベントからクリーンアップジョブを実行し、遅延ビルドが新しいプレビューを削除するのを防ぐチェックを追加してください。

ワークフローは、イベントペイロードからリポジトリとプルリクエスト番号を受け取ります。プレビューチャネル名を再構築してください。プルリクエストコメントまたは信頼できないブランチ変数からチャネル名を受け取らないでください。

有用なジョブシーケンスは次のようになります。

暗号化されたシークレットから制限されたクリーンアップキーを読み込みます。
イベントがクローズされたプルリクエストであることを確認します。
期待どおりのリポジトリとアプリに属しているプレビューを確認します。
アクティブプレビューデプロイメントが完了するのを待ちます。
プレビューから切り替えます。resetPreview.
プレビューのバンドルIDをリストする。
各バンドルを削除する。
プレビューのレコードを削除する。
ワークフローの概要に短い結果を書き込む。

順序は重要です。最初に削除すると、有効なプレビューのルールがリクエストをブロックする可能性があります。リスト呼び出しをスキップすると、まだ存在するバンドルIDを知ることができません。予測された名前で削除すると、間違ったリソースにアクセスするリスクがあります。

Pull Request プレビュークリーンアップの自動化された CI/CD ワークフロー

Pull Request番号に基づいて並列ルールを使用する。クローズイベントとリビルドイベントが近い時間に到着すると、古いクリーンアップジョブは新しいデプロイメントと競合しないようにする。古いクリーンアップジョブをキャンセルするか、デプロイロックが解放されるまでジョブを待つ。

Capgoの1コマンドCLIワークフローは、ビルドとリリースワークの周りでカスタムシェルコールの数を減らすことができます。コマンド名とサポートされている操作については、Capgo CLIコマンドドキュメントを参照してください。 Capgoを使用すると、検証されたコマンドが得られます。CLIまたはパブリック__CAPGO_KEEP_2__を使用すると、直接リクエストが必要なクリーンアップアクションが得られます。.CLIを使用して、検証されたコマンドが得られる場所で使用してください。 SDK または公開された API を使用して、クリーンアップアクションに直接要求する必要がある場所で使用してください。

__CAPGO_KEEP_0__ __CAPGO_KEEP_1__コマンドドキュメント

キャップゴーでプルリクエストプレビューのクリーンアップAPIキーを設定してください。プルリクエストのクローズイベントが失敗した場合、スケジュールされたジョブは、チームの許可されたテストウィンドウよりも古いプレビューを検索できます。このジョブには、通常のクローズホックよりも厳格なセーフガードが必要です。プレビューの所有者が明確でタイムスタンプが期限切れであるプレビューのみを選択する必要があります。

キャップゴーでGitHubアクションの場合、許可を狭くし、クリーンアップステップに必要な値のみを渡してください。Capgoの現在のGitHubアクションの統合ドキュメントでは、トークンが保存されている場所とワークフローがCapgoに接続されている方法が説明されています。

この時点で、クロージャーに反応し、競合するジョブを待ち、有効な状態をリセットし、IDをリストし、対象のバンドルのみを削除する自動化されたパスを持っているはずです。これは、毎日開発に十分なスピードで、クリーンアップを無謀なスツールとして扱わないようにします。

ステップ 6: クリーンアップの検証とロールアウトの誤削除保護

Pull request preview cleanup loopを閉じるには、Capgoを閉じる必要があります。安全なリリースプロセスには、単に削除のレスポンスだけでは十分ではありません。

検証はプルリクエストプレビューのクリーンアップループを終了します。削除のレスポンスだけでは、安全なリリースプロセスには十分ではありません。

ジョブサマリーに次の値を保存してください。

ジョブのサマリーに次の値を保存してください:
リポジトリとプルリクエスト番号。
プレビューチャネル名。
所有権の確認に使用したコミット SHA。
見つかったバンドル ID。
エラーが発生したIDのいずれか。

明確なステータスを使用してください。 "Cleaned" は、すべての検証対象が消えていることを意味します。 "Already clean" は、リソースがこの実行前に欠けていたことを意味します。 "Needs review" は、1 つ以上のチェックが失敗したことを意味します。一部の削除を成功としてラベル付けしないでください。

code にプロダクションガードを追加してください。デフォルトまたはリリースチャンネルのようなチャンネル名を拒否します。また、プレビューアプリのメタデータと一致しないバンドルも拒否します。ガードは失敗したときに閉じるようにしてください。スクリプトが対象を信頼できなくなる場合は、停止してください。

ロールバックとクリーンアップを別々に維持してください。ロールバックは、デバイスが受け取るバンドルの変更になります。クリーンアップは古いプレビューリソースの削除になります。プルリクエストがクローズした後、テストでバグが見つかった場合は、バンドルを調査するために必要になるかもしれません。したがって、チームがマージ後にデバッグすることが多い場合は、短い保持期間を設定するのではなく、イベントが到着したときに即座に削除しないでください。

3 つの一般的な失敗パターンを監視してください。

アクティブプレビューエラー: リセットまたは切り替えを実行して、再試行する "Delete Preview" を実行してください。
バンドル ID が欠けている: リストアクションを再実行してください。予測を避けましょう。
許可エラー: キースコープを確認し、必要に応じて新しいキーを発行してください。

セキュリティポリシーで設定したスケジュールに従って、クリーンアップキーを回転してください。ログまたはコミットに表示された場合、即座に回転してください。新しいキーは、古いキーが削除される前にテストしてください。ただし、漏洩が即時削除を必要とする場合は、除外せずに新しいキーをテストしてください。

セキュリティレビューの際に、SDKと検証済みのCapgoガイドラインを実装の元として扱い、リクエスト契約をバージョン管理下に置く。

キーアピール: codeのプレビューとバンドルリストを削除した後、codeで生産ターゲットをブロックし、部分的なクリーンアップを失敗として報告する。

__CAPGO_KEEP_0__のガードレールが明確な場合にのみ、1つのコマンドが有効になる。プレビューを追跡する。予測可能なチャンネル名を採用する。リリース変更を別途ロールバックする。最後に、クリーンアップジョブがライブトラフィックに触れることなく、自分の小さな仕事を実行するようにする。

FAQ

Can I delete an active Capgo pull request preview?

__CAPGO_KEEP_0__のプレビューを削除できるか?resetPreviewいいえ。アクティブなプレビューは最初に切り替えなければならない、または Capgo を呼び出す必要がある。アクティブな状態がクリアされた後、Delete Preview を実行する。このルールは、Capgo プレビュークリーンアップ API キーを CI で設定する際に、主な詳細を思い出させる必要がある。

Capgo プレビューをクリーンアップするには、バンドル ID が必要ですか?

はい。Capgo の Delete Bundle アクションにはバンドル ID が必要なので、削除する前に利用可能なバンドルをリストアップし、プレビューチャンネルとコミットに各 ID をマッチさせて、削除要求を送信する。ブランチ名から ID を作成しないでください。また、プレビューを削除しても、すべてのバンドルが削除されるわけではありません。

CI でプレビュークリーンアップに使用する API キーの種類は何ですか?

Use a restricted App Preview key for preview cleanup, stored in your CI provider’s encrypted secret store. Limit the key to the app or scope it needs. Keep it separate from the key used to publish production updates. This makes the Capgo cleanup job easier to review and safer to rotate.

プルリクエストがクローズされたときにクリーンアップを自動化できますか?

はい。クローズされたプルリクエストイベントからクリーンアップをトリガーし、有効なデプロイジョブが完了するまで待ってからプレビューをリセットします。バンドル ID のリストを表示し、検証されたマッチを削除し、結果を確認します。同時実行制御を追加して、クリーンアップジョブに遅れてもビルドがクリーンアップジョブを上回らないようにします。

CapgoのCapgoクリーンアップリクエストはなぜ失敗していますか。

通常の原因は、有効なプレビュー、バンドル ID の欠如、または必要なスコープを持たないキーの欠如です。プレビューをリセットし、リスト呼び出しを繰り返し、キーの権限を検査してください。リクエストの詳細は API または SDK のバージョンによって異なるため、スクリプトを変更する前に現在の方法とパラメーターを確認してください。

結論

Capgo をプレビューキーと厳密なクリーンアップ順序と組み合わせて使用します: 有効なプレビューをリセットし、バンドル ID のリストを表示し、検証されたバンドルを削除し、最後にプレビューを削除します。1 つのクローズされたプルリクエストに対してドライランを実行し、現在の SDK のリクエストシェイプを確認し、生産チャネルガードを追加する前に自動クリーンアップを有効にします。

Capgo プルリクエストプレビュークリーンアップ API キー

目次

ステップ 1: プレビュー クリーンアップ用に制限された Capgo API キーを作成する

ステップ 2: プルリクエスト プレビューとそのバンドル ID を特定する

ステップ 3: アクティブ プレビューから切り替えてクリーンアップ

ステップ 4: プレビュー バンドルを ID で削除するには、API キーを使用します。

ステップ 5: プル リクエストがクローズされたときにクリーンアップを自動化する