メイン コンテンツにスキップ

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

プルリクエスト プレビュー クリーンアップの安全な実行、有効なプレビューのリセット、バンドルの削除、および CI/CD クリーンアップの自動化を実行するには、Capgo API キーを使用する方法を学びます。

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

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

目次

  • ステップ 1: プレビュー クリーンアップ用に制限された Capgo API キーを作成する
  • ステップ 2: プル リクエスト プレビューとそのバンドル ID を特定する
  • ステップ 3: クリーンアップ前にプレビューから切り離す
  • ステップ 4: API キーを使用してバンドルを ID で削除する
  • ステップ 5: プル リクエストがクローズされたときにクリーンアップを自動化する
  • ステップ 6: クリーンアップを確認し、誤って削除されるのを防ぐ
  • FAQ
  • まとめ

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

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

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

In Capgo, start with an App Preview key for preview work. The key should be tied to the app or preview scope that your job manages. If your team uses role-based access control, limit the key to selected apps instead of granting access across the whole organization. Capgo documents those preview key choices in its API キー設定.

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

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

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

CapgoのプレビュークリーンアップAPIキーを、実行用のキーとは別に管理してください。実行用のジョブはリリースをアップロードする必要があるかもしれませんが、クリーンアップジョブはプレビュー資源のみを削除する必要があります。別々のキーを使用すると、削除アクションが実行チャネルに到達する可能性を減らし、レビューが容易になります。

可能な場合は、保護された環境で同じシークレットを使用してください。ジョブが共有チャネルにアクセスする前に、承認を求めるようにしてください。通常のプルリクエストプレビューの場合、ジョブは一時チャネルでしか動作しないようにしてください。

重要なポイント: Capgoのプレビュー用APIキーを使用し、制限されたアプリスコープで使用し、暗号化されたCIシークレットに保管してください。

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

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

Capgo プルリクエスト プレビュー クリーンアップ API キーは、ジョブが所有するプレビューとバンドル ID を知っている場合にのみ有効です。

CapgoのプレビュークリーンアップAPIキーは、ジョブが所有するプレビューとバンドルIDを知っている場合にのみ有効です。

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

次に、そのプレビューに紐づくバンドルの一覧を表示します。CapgoのDelete BundleアクションにはバンドルIDが必要です。ソース ドキュメントは、削除する前にすべての利用可能なバンドルIDを取得するためのリスト呼び出しに指示しています。リストを真実の元として扱い、ファイル名、コミット ハッシュ、ブランチ名からIDを推測しないでください。

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

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

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

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

Capgoの公開API Capgoの公開APIの概要 __CAPGO_KEEP_0__の公開__CAPGO_KEEP_1__

__CAPGO_KEEP_0__のプレビューID、正確なバンドルIDのリスト、各レコードに紐づいたコミットSHAを持っているはずです。 1 つでもその値が欠けている場合はここで止めます。 所有権チェックなしのクリーンアップは、賭けです。

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

アクティブなプレビューは、プレビューから切り替えるか、またはそのアプリを呼び出すまで削除できません。resetPreviewCapgoのプルリクエストプレビュークリーンアップフローにおけるこのキー詳細は、Capgo プルリクエストプレビュークリーンアップフローにおけるこのキー詳細は、

Think of the active preview as the version currently selected by the app. Deleting the server-side record first would leave the app pointing at something that no longer exists. Capgo blocks that state change, so your cleanup job must reset the app’s preview state before it removes the preview.

__CAPGO_KEEP_0__

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

ここには便利な順序付けのルールがあります:

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

Do not treat a successful HTTP response from the reset request as proof that the app has already changed state on every device. A device may check for updates later. Your server-side cleanup can still proceed once the preview assignment has been cleared according to the API response, but keep device behavior separate from resource deletion.

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

Capgoを使用するチームが厳密な境界を必要とする場合、ドキュメントに記載されている Capgo__CAPGO_KEEP_0__

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

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

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

ステップ 4: ID でプレビュー バンドルを削除する ( API キーを使用 )

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

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

SDK メソッドのサインャーを確認するか、 Capgo サポートと確認してください。 その後、チームの内部の実行本を更新して、メソッドとレスポンス形式を記録してください。 その実行本には、 API バージョン、必要な識別子、リトライ ロジックが処理できるエラーコードを含める必要があります。

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

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

  1. バンドル ID が存在しない、または不正な場合を拒否します。
  2. プル リクエスト プレビューと一致しないチャネルを持つバンドルを拒否します。
  3. 所有権チェックが通過した後のみ削除します。

次に、各レスポンスをタイプごとに処理します。成功した削除は完了として記録できます。存在しないレスポンスは、リソースが以前の再試行によって削除されたことがわかっている場合、すでにクリーンとして扱うことができます。許可エラーはジョブを失敗させてオーナーに警告します。レート制限は一時的なエラーを再試行し、最大実行時間を設定して、CI キューを占有しないようにします。

すべてのエラーを再試行しないでください。有効な ID には 3 回の試行後も変わりません。認証エラーは通常、キー スコープが不正であることを意味します。再試行は一時的なエラーのみで、最大実行時間を設定して、ジョブが CI キューを占有しないようにします。

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

機密情報を含まない削除ログを維持する。プルリクエスト番号、プレビュー名、バンドルID、リクエスト結果、タイムスタンプをログすることは問題ありません。API キー、認証ヘッダー、またはリクエストオブジェクトを含む可能性があるため、API キー、認証ヘッダー、またはリクエストオブジェクトをログしないようにしてください。

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

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

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

ワークフローはイベントペイロードからリポジトリとプルリクエスト番号を受信する必要があります。リポジトリとアプリの期待値に基づいてプレビュー チャンネル名を再構築します。プルリクエスト コメントまたは信頼できないブランチ変数からチャンネル名を受け入れないでください。

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

  1. 暗号化されたシークレットから制限されたクリーンアップキーをロードします。
  2. イベントがクローズされたプルリクエストであることを確認します。
  3. 期待値のリポジトリとアプリに属するプレビューが存在することを確認します。
  4. アクティブなプレビュー デプロイメントが完了するのを待ちます。
  5. プレビューから切り替えるか呼び出しresetPreview.
  6. 指定されたプレビューのバンドル ID のリストを取得します。
  7. 各バンドルを削除してください。
  8. プレビューのレコードを削除してください。
  9. ワークフロー サマリーに短い結果を書き込んでください。

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

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

プル リクエスト番号に基づいて並行性のルールを使用してください。クローズ イベントとリビルド イベントがほぼ同時に到着した場合、古いクリーンアップ ジョブは新しいデプロイメントと競合しないようにしてください。古いクリーンアップ ジョブをキャンセルするか、デプロイメント ロックが解除されるまでジョブを待ってください。

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

リテンションのフォールバックを設定してください。クローズ イベントがミスされた場合、スケジュール ジョブはチームの許可するテスト ウィンドウよりも古いプレビューを発見する可能性があります。そのジョブには、より厳格な安全対策が必要です。プレビューが明確なオーナーと期限切れのタイムスタンプを持つ場合にのみ選択してください。

__CAPGO_KEEP_0__のワン コマンド__CAPGO_KEEP_1__ワークフローは、ビルドとリリースの作業の周りでカスタム シェル コールの数を減らすことができます。コマンド名とサポートされている操作については、__CAPGO_KEEP_0__ __CAPGO_KEEP_1__コマンド ドキュメントを参照してください。

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

現在、自動化されたパスがクローズに反応し、競合するジョブを待ち、有効な状態をリセットし、IDをリストし、対象のバンドルのみを削除することができているはずです。これは、毎日開発に十分なスピードで、クリーンアップを無謀なブラシとして扱うことなく、実行できます。

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

検証により、Capgo プルリクエスト プレビュー クリーンアップループが閉じます。安全なリリースプロセスには、単に削除応答だけでは十分ではありません。

クリーンアップジョブが実行された後、プレビュー チャンネルを確認し、再び有効なプレビューとして表示されていないことを確認します。次に、同じアプリとフィルタでバンドルリストを確認します。期待される結果は、対象のバンドル ID が消え、生産バンドルが残っていることです。

ジョブの概要に次の値を保存します:

  • リポジトリとプルリクエスト番号。
  • プレビュー チャンネル名。
  • 所有権チェックに使用したコミット SHA。
  • 見つかったバンドル ID。
  • 削除されたバンドル ID。
  • エラーを返した ID。

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

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

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

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

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

クリーンアップ キーを定期的にローテートし、ログまたはコミットに表示された場合は即座にローテートしてください。 新しいキーは、古いキーが削除される前にテストする必要があります。 ただし、漏洩が即時削除を必要とする場合は、除外する必要があります。

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

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

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

FAQ

Can I delete an active Capgo pull request preview?

アクティブな__CAPGO_KEEP_0__プルリクエストプレビューを削除できますか?resetPreview. After the active state clears, run Delete Preview. This rule is the main detail to remember when setting up a Capgo pull request preview cleanup API key in CI.

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

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

CI はプレビュークリーンアップのためにどのような API キーを使用するべきですか。

CI プロバイダーの暗号化されたシークレット ストアに保存されている App プレビュー キーを使用してプレビュー クリーンアップを実行し、キーをアプリまたは必要なスコープに制限してください。キーをプロダクション アップデートの公開に使用するキーと分離してください。これにより、Capgo クリーンアップ ジョブをレビューしやすく、キーを回転するときに安全になります。

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

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

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

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

まとめ

Capgo を使用して、プレビュー キーと厳格なクリーンアップ順序でプレビュー クリーンアップを実行してください。有効なプレビューをリセットし、バンドル ID をリストし、検証されたバンドルを削除し、プレビューを削除してください。1 つのクローズされたプル リクエストに対してドライ ラン実行を開始し、現在の SDK でリクエストの形状を確認し、生産チャネル ガードを追加する前に自動クリーンアップを有効にします。

Capacitorアプリの即時更新

Capgoアプリの即時更新の説明

マーティンから人間のサポート

はじめに

__CAPGO_KEEP_0__はあなたに最も必要な洞察を提供して、実際にプロフェッショナルなモバイルアプリを作成するのに役立ちます。

Capgoアプリの2方向のコミュニケーション