Capgo Pull Request Preview Reinigung API Schlüssel

Löschen eines Pull-Request-Vorschau-Beitrags sieht wie ein Ein-Befehl-Job aus. Mit Capgo, gibt es jedoch einen Haken: Sie müssen sich von einem aktiven Vorschau weg bewegen, bevor Sie es löschen, dann müssen Sie die Pakete durch ID entfernen. Wir werden einen sicheren Reinigungsfluss mit einem eingeschränkten API Schlüssel, Vorschauabfrage, Reset-Handling, Paketlöschung und CI-Automatisierung erstellen.

Inhaltsverzeichnis

• Step 1: Create a Restricted Capgo API Key for Preview Cleanup
• Schritt 2: Identifizieren Sie den Pull Request Vorschau und seine Paket-IDs
• Schritt 3: Wechseln Sie vor der Reinigung vom aktiven Vorschau-Modus
• Schritt 4: Löschen Sie die Vorschau-Pakete durch ID mit dem API Schlüssel
• Schritt 5: Automatisiere die Reinigung bei geschlossener Pull-Anfrage
• Schritt 6: Überprüfe die Reinigung und schütze die Rollouts vor ungewollter Löschung
• FAQ
• Zusammenfassung

Schritt 1: Erstellen Sie einen eingeschränkten Capgo API-Schlüssel für die Vorabreinigung

Der erste Schritt in einem Capgo-Pull-Request-Vorschaubereinigungsfloß ist es, einen Schlüssel zu erstellen, der nur die Arbeit ausführen kann, die Ihre CI-Aufgabe benötigt.

Stellen Sie keinen breiten Organisationsschlüssel in einen Pull-Request-Workflow ein. Ein Pull-Request kann von einem Zweig kommen, der noch nicht vertrauenswürdig ist. Der Workflow kann auch eine Anweisung oder einen Umgebungswert während eines fehlgeschlagenen Laufs ausgeben. Ein enger Schlüssel begrenzt die Schäden, wenn das passiert.

In Capgo beginnen Sie mit einem App-Vorschau-Schlüssel für Vorschauarbeit. Der Schlüssel sollte an das App oder Vorschau-Scope gebunden sein, das Ihre Aufgabe verwaltet. Wenn Ihr Team eine role-basierte Zugriffskontrolle verwendet, beschränken Sie den Schlüssel auf ausgewählte Apps anstatt Zugriff auf die gesamte Organisation zu gewähren. Capgo dokumentiert diese Vorschau-Schlüsselwahlen in seinen API Schlüsselinstellungen für Web-App-Workflows.

Speichern Sie den geheimen Schlüssel in Ihrem CI-Anbieters verschlüsselten Geheimtextspeicher. Geben Sie ihm einen Namen, der sagt, was er tut, wie z. B.CAPGO_PREVIEW_CLEANUP_KEYPlatziere es nicht in einer Workflow-Datei, einer Shell-Skriptdatei, einem Pull-Request-Kommentar oder einer generierten Protokolldatei.

Übergeben Sie den Schlüssel an den Bereinigungsprozess über eine Umgebungsvariable. Ihr Skript sollte fehlschlagen, wenn die Variable fehlt. Ein stummer Ausfall ist gefährlich, da er einen Bereinigungsjob in einen Anforderung ohne Authentifizierung verwandeln oder einen Entwickler dazu bringen kann, einen Schlüssel in die Befehlszeile einzufügen.

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

Behalte diese Schlüssel getrennt von dem Schlüssel, der zum Veröffentlichen von Produktionsbündeln verwendet wird. Die Veröffentlichungsaufgabe muss möglicherweise eine Veröffentlichung hochladen. Die Reinigungsarbeit benötigt nur die Entfernung von Vorschauressourcen. Trennte Schlüssel erleichtern die Überprüfung und reduzieren die Wahrscheinlichkeit, dass eine Löschaktion auf ein Produktionskanal trifft.

Verwende denselben geheimen Schlüssel in einem geschützten Umfeld, wenn möglich. Erstelle eine Genehmigung vor, bevor eine Aufgabe einen gemeinsamen Kanal berühren kann. Für gewöhnliche Pull-Request-Vorschau, sollte die Aufgabe auf einem temporären Kanal arbeiten und nichts anderes.

Schlüssel-Merkpunkt: Use a dedicated App Preview key, limit its app scope, and keep it in encrypted CI secrets.

Bevor du fortfährst, teste den Schlüssel gegen eine harmlose Leseanfrage. Bestätige, dass die Aufgabe den beabsichtigten App sehen kann, aber keinen anderen App oder Produktionsworkflow zugreifen kann. Die genauen Anforderungen für die Reinigung werden nicht vollständig veröffentlicht, also halte deine erste Test klein und überprüfe die SDK oder Capgo-Support-Richtlinie, bevor du Löschaufrufe hinzufügst.

Schritt 2: Identifiziere die Pull-Request-Vorschau und ihre Bundle-IDs

Der Capgo Pull-Request-Vorschau-ReinigungsAPI-Schlüssel ist nur dann nützlich, wenn Ihr Job weiß, welche Vorschau- und Bundle-IDs er besitzt.

Verwende eine stabile Namensregel für Vorschaukanäle. Ein häufiges Muster ist der Repositoryname plus die Pull-Request-Nummer. Der Hauptschwerpunkt ist die Konsistenz. Deine Reinigungsarbeit muss den gleichen Identifier nach dem Schließen der Pull-Request wieder aufbauen.

Speichern Sie den Namen des Vorschaukanals, wenn die Vorschau erstellt wird. Sie können ihn in der Workflowausgabe, einem Pull-Request-Check oder einem kleinen Stück Job-Metadaten platzieren. Verlassen Sie sich nicht auf einen Anzeigennamen, den ein Benutzer im Dashboard ändern kann.

Als Nächstes listet die Pakete auf, die mit dieser Vorschau verbunden sind. Capgo’s Löschen-Paket-Aktion erfordert Paket-IDs. Die Quellendokumentation verweist auf eine Listeaufrufanweisung zur Abholung aller verfügbaren Paket-IDs vor der Löschung. Behandeln Sie diese Liste als Quelle der Wahrheit. Raten Sie keine ID aus einem Dateinamen, einem Commit-Hash oder einem Branch-Namen.

Filtern Sie die zurückgegebenen Datensätze nach dem Vorschaukanal oder einem anderen Wert, den Ihr Workflow steuert. Halten Sie dann den genauen Paket-Id für jeden Treffer auf. Wenn die Liste leer ist, markieren Sie die Reinigung als abgeschlossen. Ein leerer Ergebnis ist nicht ein Fehler, es sei denn, Ihr Workflow erwartet eine Vorschau.

Auch das Commit-SHA, das jede Vorschau produziert, aufzeichnen. Dies gibt Ihnen eine zweite Überprüfung vor der Löschung. Wenn der Kanalname übereinstimmt, aber das Commit nicht, stoppen Sie und bitten Sie um eine Überprüfung. Diese kleine Pause kann einen Rennlauf verhindern, bei dem eine neue Vorschau erstellt wird, während ein altes Reinigungsjob läuft.

Löschungen während eines laufenden Veröffentlichungsjobs vermeiden. Fügen Sie eine Abhängigkeit zwischen der Vorschau- und der Reinigungsworkflow hinzu oder verwenden Sie einen Schlüssel, der an der Pull-Request-Nummer geknüpft ist. Die Reinigungsarbeit sollte erst nach dem Close-Ereignis und nach Beendigung aller ausstehenden Vorschau-Uploads starten.

Capgo’s public API covers resources such as channels and bundles through authenticated HTTP requests, but the cleanup actions still need careful verification in your project. The Capgo öffentliche API-Übersicht ist der richtige Ort, um die aktuelle Ressourcenstruktur zu bestätigen, bevor Sie einen Wrapper schreiben.

Wenn Sie nun ein Vorschau-Identifikator, eine Liste exakter Bundle-IDs und den Commit-SHA haben, der jeder Aufzeichnung zugeordnet ist, sollten Sie hier aufhören. Die Reinigung ohne Eigentümerprüfungen ist Spekulation.

Schritt 3: Wechseln Sie vom aktiven Vorschau weg, bevor Sie reinigen

Ein aktives Vorschau kann nicht gelöscht werden, bevor das App sich von ihm wechselt oder Sie resetPreviewDies ist der Schlüsselpunkt im Capgo Pull-Request-Vorschau-Reinigungsfluss.

Denken Sie an die aktive Vorschau als die Version, die der App derzeit ausgewählt hat. Wenn Sie die serverseitige Aufzeichnung zuerst löschen, würde die App auf etwas zeigen, das nicht mehr existiert. Capgo blockiert diesen Zustandswechsel, daher muss Ihre Reinigungsaufgabe die App-Vorschau-Zustand vor der Entfernung der Vorschau zurücksetzen.

Zuerst prüfen Sie, ob die Vorschau noch aktiv ist. Wenn sie es ist, bewegen Sie die App in einen sicheren Kanal oder verwenden Sie die Updater-Reset-Aktion. Die richtige Wahl hängt davon ab, wie Ihre Test-App konfiguriert ist. Eine verbrauchbare Test-App kann wieder auf ihren normalen Standardkanal zurückkehren. Eine geteilte Test-App benötigt möglicherweise einen dedizierten Staging-Kanal anstatt.

VerwendenresetPreviewWenn der Vorschauzustand direkt gelöscht werden muss. Halten Sie diese Anfrage an demselben Pull-Request und der Anwendung fest, die die Vorschau erstellt hat. Ein Reinigungsskript sollte nie eine Produktionsgeräte oder einen geteilten Release-Kanal zurücksetzen, nur weil der Kanalname zufällig übereinstimmt.

Es gibt eine nützliche Reihenfolge von Regeln hier:

• Bestätige, dass der Pull-Antrag geschlossen ist.
• Bestätigen Sie, dass keine Vorschau-Uploads laufen.
• Wechseln Sie von der aktiven Vorschau ab oder rufen SieresetPreview.
• Warten, bis der Zustandswechsel abgeschlossen ist.
• Rufen Sie nur dann Delete Preview auf.

Behandeln Sie einen erfolgreichen HTTP-Antwort von der Reset-Anfrage nicht als Beweis dafür, dass die App bereits auf jedem Gerät den Zustand geändert hat. Ein Gerät kann später nach Updates suchen. Ihr Serverseitiger Reinigungsvorgang kann nach dem Löschvorgang der Vorschauzuweisung nach dem API-Antwort fortgesetzt werden, aber halten Sie das Geräteverhalten getrennt von der Ressourcenlösung.

Capgo unterstützt eine kanalbasierte Rollout-Kontrolle, was diese Trennung einfacher zu verstehen macht. Ein Kanal ist ein benannter Pfad, der einem App sagt, welchen Update-Stream zu folgen ist. Ihre Vorschau-Kanal sollte niemals der gleiche Kanal sein, der von Produktionsgeräten verwendet wird.

Für Teams, die eine strengere Grenze benötigen, verwenden Sie die dokumentierte Capgo-Kanal-Workflow für die Vorschau-Automatisierung. Er beschreibt das temporäre Kanal-Muster und hilft dabei, einen Reinigungsvorgang von geteilten Standardkanälen fernzuhalten.

Die offene-Quellcode-Update-Dokumentation führt auch die Löschgrenze auf: Aktive Vorschau-Bilder benötigen einen Umweg oder einen Reset vorher. Sie können die Quelle im Capgo Capacitor-Updater-Repository überprüfen. Diese Quelle ist nützlich, wenn die Dashboard-Beschreibung für eine CI-Entscheidung zu kurz ist.

Pro-Tipp: Stelle den Reset als separaten Protokollierungsschritt ein. Wenn Delete Preview fehlschlägt, sollte der Protokollzeichenfolge angezeigt werden, ob die Vorschau noch aktiv war oder ob der Löschantrag einen anderen Fehler hatte.

Einmal, wenn der aktive Zustand verschwunden ist, ist die Vorschau-Eintrag bereit für die Löschung. Löschung und Reset sollten nicht in einem undurchsichtigen Shell-Befehl kombiniert werden. Zwei klare Befehle sind einfacher zu wiederholen und viel einfacher zu überprüfen.

Schritt 4: Löschen von Vorschau-Bundles durch ID mit der API-Schlüssel

Löschen Sie jedes Vorschau-Bundle durch seine genaue ID, nachdem die aktive Vorschau zurückgesetzt wurde. Hier entfernt ein Capgo-Reinigungs-Schlüssel die durch das Pull-Request hinterlassenen Speicherobjekte.

Beginnen Sie mit der Bundle-Liste aus Schritt 2. Für jede passende ID rufen Sie die Delete-Bundle-Aktion über die Capgo SDK- oder die aktuelle öffentliche API-Methode ab, die Ihrem Konto zur Verfügung steht.

Überprüfen Sie die SDK-Methode-Signatur oder bestätigen Sie die aktuelle Anforderungsform mit Capgo-Support. Führen Sie die Methode und die Antwortformat in Ihrem internen Runbook auf, sobald Sie sie verifiziert haben. Dieses Runbook sollte die API-Version, die erforderliche Identifikation und die Fehlercodes enthalten, die Ihre Wiederholungslogik handhaben kann.

Verwenden Sie in Ihrem Skript einen Trockenlaufmodus. Es sollte den Vorschaukanal und die Paket-IDs ausgeben, die entfernt werden würden, ohne Löschanfragen zu senden. Führen Sie diesen Modus gegen mehrere geschlossene Pull-Anforderungen aus. Überprüfen Sie, ob es Produktionskanäle ausschließt und ob es eine leere Liste als Wildcard behandelt.

Ein sicheres Löschschleifen hat drei Schranken:

1. Ablehnen Sie einen fehlenden oder fehlerhaften Paket-Id.
2. Ablehnen Sie ein Paket, dessen Kanal nicht mit der Pull-Anforderungsvorschau übereinstimmt.
3. Löschen Sie nur, nachdem die Eigentümerschranke besteht.

Behandeln Sie dann jeden Antworttyp. Ein erfolgreicher Löschvorgang kann als abgeschlossen aufgezeichnet werden. Eine nicht-gefundene Antwort kann als bereits sauber behandelt werden, wenn das Ressourcenobjekt als entfernt durch einen früheren Wiederholungsversuch bekannt ist. Zulassungsfehler sollten den Job abbrechen und den Besitzer benachrichtigen. Rate-Grenzen sollten pausieren und mit einem begrenzten Zeitabstand erneut versuchen.

Versuchen Sie nicht jeden Fehler. Ein schlechter ID wird nicht nach drei Versuchen gültig. Eine Autorisierungsfehler bedeutet normalerweise, dass der Schlüsselscope falsch ist. Versuchen Sie nur vorübergehende Fehler und setzen Sie eine maximale Ausführungszeit, damit ein steckengebliebener Reinigungsauftrag Ihre CI-Warteschlange nicht konsumiert.

Die Paketlöschung ist von der Vorschau-Löschung getrennt. Die Entfernung des Vorschaukanals beweist nicht automatisch, dass jedes Paket entfernt wurde. Ihr Job sollte für jede ID einen Ergebniswert behalten, dann stellen Sie eine finale Listeanfrage, wenn der API es unterstützt. Wenn noch ein Paket übrig bleibt, melden Sie die ID und beenden Sie den Job, anstatt stillschweigend Erfolg zu behaupten.

Bleiben Sie die Löschprotokolle frei von Geheimnissen. Es ist in Ordnung, die Pull-Request-Nummer, den Vorschau-Namen, den Bundle-ID, den Anforderungsresultat und den Zeitstempel zu protokollieren. Loggen Sie jedoch nie die API-Schlüssel, einen Autorisierungsheader oder ein vollständiges Anforderungsobjekt, das einen davon enthalten könnte.

Diese Vorgehensweise gibt Ihnen einen nützlichen Audit-Trail ohne die Protokolldatei in einen anderen Ort zu verwandeln, an dem sich Geheimnisse ausbreiten könnten. Es macht auch einen fehlgeschlagenen Reinigungsvorgang leicht wieder aufzunehmen, da der nächste Lauf die bereits als abwesend bestätigten Einträge überspringen kann.

Schritt 5: Automatisierung der Reinigung bei geschlossener Pull-Request

Führen Sie den Reinigungsjob aus dem Pull-Anforderungs-Schließen-Ereignis aus, aber fügen Sie Überprüfungen hinzu, die verhindern, dass ein spätes Build ein neues Vorschau-Objekt löscht.

Ihre Workflow-Instanz sollte die Repository- und Pull-Request-Nummer aus dem Ereignis-Payload erhalten. Rekonstruieren Sie den Vorschau-Kanalnamen aus diesen Werten. Nehmen Sie keinen Kanalnamen an, der von einem Pull-Request-Kommentar oder einem unvertrauenswürdigen Branch-Variable bereitgestellt wird.

Ein nützlicher Job-Sequence sieht wie folgt aus:

1. Load the restricted cleanup key from encrypted secrets.
2. Confirm the event is a closed pull request.
3. Überprüfen Sie, ob die Vorschau dem erwarteten Repository und App gehört.
4. Warten Sie, bis jede aktive Vorschau-Veröffentlichung abgeschlossen ist.
5. Wechseln Sie von der Vorschau weg oder rufen SieresetPreview.
6. Liste die Bundle-IDs für diese Vorschau.
7. Löschen Sie jede verifizierte Paketversion.
8. Löschen Sie das Vorschau-Protokoll.
9. Erfolgreiche Ergebnisse in der Workflow-Zusammenfassung schreiben.

Die Reihenfolge ist wichtig. Wenn Sie zuerst löschen, kann die aktive Vorschau-Regel den Antrag blockieren. Wenn Sie die Listeaufruf überspringen, wissen Sie möglicherweise nicht, welche Paket-IDs noch existieren. Wenn Sie nach einem vermuteten Namen löschen, riskieren Sie, das falsche Ressourcen anzusprechen.

Verwenden Sie eine Konkurrenzregel, die an der Pull-Request-Nummer gekennzeichnet ist. Wenn ein Schließenereignis und ein Rebuildereignis in der Nähe der gleichen Zeit eintreffen, sollte der alte Reinigungsjob nicht mit dem neuen Deployment konkurrieren. Stornieren Sie einen veralteten Reinigungsjob oder lassen Sie den Job warten, bis der Deployment-Sperre aufgehoben ist.

Capgo’s Einfach-Befehl-CLI-Workflow kann die Anzahl der benutzerdefinierten Shellaufrufe um die Arbeit mit Build und Release reduzieren. Für Befehlsnamen und unterstützte Operationen überprüfen Sie die Capgo CLI-Befehlsdokumentation . Verwenden Sie den CLI, wenn er Ihnen einen verifizierten Befehl gibt. Verwenden Sie den SDK oder den öffentlichen API, wenn Reinigungsaktionen einen direkten Antrag benötigen.

Legen Sie die Reinigung nicht in einen Workflow ein, der mit jedem Push ausgeführt wird. Ein Push-Job kann eine Vorschau entfernen, die noch getestet wird. Das Schließenereignis ist der richtige Trigger für die normale Reinigung. Fügen Sie einen manuellen Workflow-Dispatch für die Wiederherstellung hinzu, wenn ein Job fehlschlägt.

Setzen Sie einen Retentionsfall zurück. Wenn ein Schließenereignis ausgelassen wird, kann ein geplanter Job Vorschauen finden, die älter als das zulässige Testfenster Ihrer Team sind. Der Job benötigt strengere Sicherheitsvorkehrungen als die normale Schließen-Hook. Er sollte nur Vorschauen mit einem klaren Eigentümer und einem abgelaufenen Timestamp auswählen.

Für GitHub Aktionen sollten Sie die Berechtigungen eng halten und nur die Werte übergeben, die für den Reinigungsprozess erforderlich sind. Capgo’s aktuelle GitHub Aktionen-Integration-Dokumentation erklärt, wo der Token gespeichert ist und wie der Workflow mit Capgo verbunden ist.

Sie sollten jetzt einen automatisierten Weg haben, der auf Schließen reagiert, auf konkurrierende Jobs wartet, den aktiven Zustand zurücksetzt, IDs auflistet und nur übereinstimmende Pakete löscht. Das ist schnell genug für den täglichen Entwicklungsprozess, ohne dass die Reinigung zu einem blinden Besen wird.

Schritt 6: Überprüfung der Reinigung und Schutz von Rollouts vor ungewollter Löschung

Die Verifizierung schließt den Capgo Pull-Request-Vorschau-Überprüfungszyklus. Ein Löschantwort reicht für einen sicheren Releaseprozess nicht aus.

Nachdem der Reinigungsjob abgeschlossen ist, überprüfen Sie den Vorschaukanal erneut. Bestätigen Sie, dass er nicht mehr als aktiver Vorschaukanal erscheint. Dann überprüfen Sie die Paketliste für das gleiche App und filtern Sie. Das erwartete Ergebnis ist, dass die Ziel-Paket-IDs weg sind, während die Produktionspaket-IDs übrig bleiben.

Speichern Sie diese Werte in der Job-Zusammenfassung:

• Repository und Pull-Request-Nummer.
• Vorschaukanalname.
• Commit SHA für Eigentumsprüfungen verwendet.
• Gefundene Paket-IDs.
• Gelöschte Paket-IDs.
• Jede ID, die einen Fehler zurückgibt.

Verwenden Sie einen klaren Status. „Gereinigt“ bedeutet, dass alle überprüften Ziele entfernt sind. „Bereinigt“ bedeutet, dass die Ressource vor diesem Lauf abwesend war. „Braucht Überprüfung“ bedeutet, dass eine oder mehrere Überprüfungen fehlgeschlagen sind. Labelen Sie keine teilweise Löschung als Erfolg.

code sollte einen Produktionswächter enthalten. Ablehnen Sie Kanalnamen wie Ihren Standard- oder Release-Kanal. Ablehnen Sie auch ein Bundle, wenn dessen Metadaten nicht mit der Vorschau-App übereinstimmen. Der Wächter sollte fehlschlagen. Wenn das Skript den Zielwert mit Sicherheit nicht identifizieren kann, sollte es aufhören.

Halten Sie Rollback und Bereinigung getrennt. Ein Rollback ändert, welches Bundle-Geräte erhalten. Die Bereinigung entfernt eine alte Vorschau-Ressource. Wenn ein Test nach dem Schließen des Pull-Requests einen Fehler findet, benötigen Sie möglicherweise das Bundle für die Untersuchung. Setzen Sie einen kurzen Aufbewahrungszeitraum anstelle der sofortigen Löschung, wenn Ihr Team häufig nach dem Merge debuggt.

Beachten Sie drei häufige Fehlermuster:

• Aktive Vorschau-Fehler: Resetten oder wechseln Sie weg, bevor Sie Delete Preview erneut ausführen.
• Fehlender Bundle-Id: Führen Sie die Liste-Aktion erneut aus, anstatt zu raten.
• Zugriffsfehler: review the key scope, then issue a new key if needed.

Rotieren Sie die Bereinigungsschlüssel nach einem von Ihrer Sicherheitspolitik festgelegten Zeitplan und rotieren Sie sie sofort, wenn sie in einem Protokoll oder Commit erscheinen. Ein neuer Schlüssel sollte vor der Abrufung des alten getestet werden, es sei denn, die Exposition erfordert eine sofortige Abrufung.

Die Dokumentationslücke rund um die Reinigung verdient einen Hinweis in Ihrer Sicherheitsprüfung. Behandeln Sie die SDK und die überprüfte Capgo-Richtlinie als Quelle für Ihre Implementierung und halten Sie Ihre eigene Anforderungskontrakt unter Versionskontrolle.

Schlüssel-Ergebnis: Überprüfen Sie die Vorschau und die Paketliste nach der Löschung, blockieren Sie die Produktionsziele in code und melden Sie einen teilweisen Reinigungsfehler.

Eine Anweisung ist nur dann nützlich, wenn die Wächterstangen klar sind. Verfolgen Sie die Vorschau. Wählen Sie einen vorhersehbaren Kanalnamen. Richten Sie die Release-Änderungen separat ein. Dann lassen Sie die Reinigungsaufgabe ihr kleines Job ohne Berührung des Live-Traffics erledigen.

FAQ

Kann ich ein aktives Capgo Pull-Request-Vorschau löschen?

Nein. Eine aktive Vorschau muss zuerst umgeschaltet werden oder Sie müssen resetPreviewaufrufen. Nachdem der aktive Zustand sich geändert hat, führen Sie Delete Preview aus. Diese Regel ist der Hauptaspekt, den Sie beachten sollten, wenn Sie ein Capgo-Pull-Request-Vorschau-Reinigungs-API-Schlüssel in CI einrichten.

Brauche ich Bundle-IDs, um eine Capgo-Vorschau zu reinigen?

Ja. Die Delete-Bundle-Aktion von Capgo erfordert die Bundle-IDs, also listet die verfügbaren Bundles vor der Löschung auf. Passen Sie jeden ID zur Vorschau-Kanal und Commit an, bevor Sie einen Löschungsbefehl senden. Bauen Sie niemals eine ID aus einem Branch-Namen oder nehmen Sie an, dass die Löschung der Vorschau auch alle Bundles entfernt.

Welche Art von API-Schlüssel sollte CI für die Vorschau-Reinigung verwenden?

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.

Can I automate cleanup when a pull request closes?

Ja. Auslösen Sie die Bereinigung vom geschlossenen Pull-Request-Ereignis aus und warten Sie auf aktive Bereitstellungsjobs, bevor Sie die Vorschau zurücksetzen. Listen Sie die Bundle-IDs auf, löschen Sie bestätigte Übereinstimmungen und bestätigen Sie das Ergebnis. Fügen Sie Konkurrenzsteuerungen hinzu, damit ein spätes Build nicht gegen die Bereinigungsaufgabe rasseln kann.

Weshalb funktioniert meine Capgo-Bereinigungsanfrage nicht?

Die üblichen Ursachen sind eine aktive Vorschau, ein fehlendes Bundle-ID oder ein Schlüssel ohne die erforderliche Ebene. Setzen Sie die Vorschau zurück, wiederholen Sie die Listeaufruf und überprüfen Sie die Schlüsselberechtigungen. Da die Anforderungsdetails je nach API oder SDK-Version variieren können, bestätigen Sie die aktuelle Methode und Parameter, bevor Sie das Skript ändern.

Zusammenfassung

Verwenden Sie Capgo mit einem dedizierten Vorschau-Schlüssel und einer strengen Bereinigungsreihenfolge: Setzen Sie die aktive Vorschau zurück, listen Sie die Bundle-IDs auf, löschen Sie bestätigte Bundle und entfernen Sie die Vorschau. Beginnen Sie mit einem Trockentest gegen eine geschlossene Pull-Request, bestätigen Sie die Anforderungsform in der aktuellen SDK und fügen Sie den Produktionskanalwächter hinzu, bevor Sie die automatische Bereinigung aktivieren.