Allez directement au contenu principal

Capgo Pull Request Preview Cleanup API Key

Learn how to use a Capgo API key to clean up pull request previews safely, reset active previews, remove bundles, and automate CI/CD cleanup.

Capgo Pull Request Preview Cleanup API Key

Deleting a pull request preview looks like a one-command job. With Capgoil y a un piège : vous devez vous éloigner d'une prévisualisation active avant de la supprimer, puis supprimer ses ensembles par ID. Nous allons construire un flux de nettoyage sécurisé avec une clé API restreinte, une recherche de prévisualisation, un traitement de réinitialisation, une suppression d'ensemble et une automatisation de CI.

Table des matières

  • Étape 1 : Créez une clé Capgo API restreinte pour la nettoyage de la prévisualisation
  • Étape 2 : Identifiez la prévisualisation de la demande de tirage et ses ID de bundle
  • Étape 3 : Passer à une autre prévisualisation avant la suppression
  • Étape 4 : Supprimer les Bundles de Prévisualisation par ID avec la clé API
  • Step 5: Automate Cleanup When a Pull Request Closes
  • Étape 6 : Vérifier la suppression et protéger les déploiements contre la suppression accidentelle
  • FAQ
  • Conclusion

Étape 1 : Créer une clé Capgo API restreinte pour la suppression de la prévisualisation

The first step in a Capgo pull request preview cleanup flow is to make a key that can do only the work your CI job needs.

Ne pas mettre une clé d'organisation large dans un flux de demande de tirage. Une demande de tirage peut provenir d'une branche qui n'a pas encore gagné la confiance. Le flux peut également imprimer une commande ou une valeur d'environnement pendant une exécution échouée. Une clé étroite limite les dommages si cela se produit.

Dans Capgo, commencez par une clé de prévisualisation d'application pour le travail de prévisualisation. La clé doit être liée à l'application ou à l'étendue de prévisualisation que votre job gère. Si votre équipe utilise un contrôle d'accès basé sur les rôles, limitez la clé aux applications sélectionnées au lieu de leur accorder accès à l'ensemble de l'organisation. Capgo documente ces choix de clés de prévisualisation dans son API key settings for web app workflows.

Stockez le secret dans le magasin de secrets chiffrés de votre fournisseur CI. Donnez-lui un nom qui indique ce qu'il fait, comme CAPGO_PREVIEW_CLEANUP_KEYN'insérez pas dans un fichier de flux de travail, un script shell, un commentaire de demande de tirage, ou un journal généré.

Transmettez la clé au processus de nettoyage à l'aide d'une variable d'environnement. Votre script devrait échouer lorsque la variable est manquante. Un redoublement silencieux est dangereux car il peut transformer un travail de nettoyage en une demande sans authentification, ou inciter un développeur à coller une clé dans la ligne de commande.

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

Conservez cette clé séparée de la clé utilisée pour publier des lots de production. Le travail de publication peut nécessiter l'envoi d'une mise à jour. Le travail de nettoyage n'a besoin que de supprimer des ressources de prévisualisation. Des clés séparées facilitent la revue et réduisent la chance qu'une action de suppression atteigne un canal de production.

Utilisez le même secret dans un environnement protégé lorsque possible. Exigez l'approbation avant qu'un travail puisse toucher des canaux partagés. Pour les prévisualisations de demande de tirage ordinaire, le travail devrait fonctionner sur un canal temporaire et rien d'autre.

Retour clé : Utilisez une clé de prévisualisation dédiée, restreignez son champ d'application et gardez-la dans des secrets CI chiffrés.

Avant de passer à l'étape suivante, testez la clé contre une action de lecture sans risque. Confirmez que le travail peut voir l'application ciblée, mais ne peut pas accéder à une application non liée ou à un flux de production. Les détails exacts de la demande de nettoyage ne sont pas pleinement publiés, donc gardez votre premier test petit et inspectez la guidance de support SDK ou Capgo avant d'ajouter des appels de suppression.

Étape 2 : Identifiez la prévisualisation de demande de tirage et ses identifiants de lot

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

Utilisez une règle de nommage stable pour les canaux de prévisualisation. Un modèle courant est le nom du dépôt plus le numéro de la demande de tirage. Le point clé est la cohérence. Votre tâche de nettoyage doit reconstruire le même identifiant après la fermeture de la demande de tirage.

Enregistrez le nom du canal de prévisualisation lors de la création de la prévisualisation. Vous pouvez le placer dans la sortie de flux de travail, une vérification de demande de tirage ou une petite pièce de métadonnée de tâche. N'ayez pas recours à un nom de display que quelqu'un pourrait modifier dans le tableau de bord.

Listez ensuite les ensembles liés à cette prévisualisation. L'action Delete Bundle de Capgo nécessite les ID des ensembles. La documentation source pointe vers une requête de liste pour récupérer tous les ID d'ensemble disponibles avant la suppression. Considérez cette liste comme la source de vérité. Ne jamais deviner un ID à partir d'un nom de fichier, d'un hachage de commit ou d'un nom de branch.

Filtrez les enregistrements retournés par le canal de prévisualisation ou une autre valeur que votre flux de travail contrôle. Gardez ensuite l'ID exact de l'ensemble pour chaque correspondance. Si la liste est vide, marquez la suppression comme complète. Un résultat vide n'est pas une erreur à moins que votre flux de travail ait attendu une prévisualisation.

Enregistrez également le SHA de commit qui a produit chaque prévisualisation. Cela vous donne une deuxième vérification avant la suppression. Si le nom du canal correspond mais le commit ne correspond pas, arrêtez et demandez une revue. Cette petite pause peut empêcher une course où une nouvelle prévisualisation est en cours de construction tandis qu'une ancienne tâche de nettoyage s'exécute.

Révision du canal de prévisualisation et de l'ID de l'ensemble pour Capgo de suppression

Do pas supprimer pendant qu'un job de publication est toujours en cours. Ajoutez une dépendance entre la construction de la prévisualisation et les workflows de nettoyage, ou utilisez un verrou cléé sur le numéro de la demande de tirage. Le job de nettoyage devrait démarrer uniquement après l'événement de fermeture et après que les téléchargements de prévisualisation en attente se soient terminés.

Les actions de nettoyage de Capgo nécessitent une vérification soigneuse dans votre projet, même si API est accessible publiquement et couvre des ressources telles que les canaux et les ensembles à l'aide de requêtes HTTP authentifiées. Capgo API : Vue d'ensemble publique La bonne place pour confirmer le modèle de ressources actuel avant d'écrire un wrapper.

À ce stade, vous devriez avoir un identifiant de prévisualisation, une liste d'IDs d'ensemble exacts et le SHA de commit lié à chaque enregistrement. Si l'un de ces valeurs manque, arrêtez-vous ici. Le nettoyage sans vérification d'appartenance est une supposition.

Étape 3 : Passer à une autre prévisualisation active avant le nettoyage

Une prévisualisation active ne peut pas être supprimée avant que l'application ne se déconnecte d'elle ou que vous appelezresetPreviewC'est le détail clé dans le flux de nettoyage de prévisualisation de demande de tirage de Capgo.

Imaginez la prévisualisation active comme la version actuellement sélectionnée par l'application. Supprimer le record côté serveur en premier laisserait l'application pointer vers quelque chose qui n'existe plus. Capgo bloque cet état de changement, donc votre job de nettoyage doit réinitialiser l'état de prévisualisation de l'application avant de supprimer la prévisualisation.

Tout d'abord, vérifiez si la prévisualisation est toujours active. Si c'est le cas, déplacez l'application vers un canal sûr ou utilisez l'action de réinitialisation de l'actualisateur. La bonne option dépend de la configuration de votre application de test. Une application de test dépourvue de valeur peut revenir à son canal par défaut normal. Une application de test partagée peut nécessiter un canal de mise en scène dédié au lieu.

UtilisezresetPreviewlorsque l'état de prévisualisation doit être clair directement. Conservez cet appel lié à la même demande de tirage et à l'application qui a créé la prévisualisation. Un script de nettoyage ne devrait jamais réinitialiser un appareil de production ou un canal de mise en production partagé simplement parce que le nom d'un canal correspond.

Il existe une règle d'ordre utile ici :

  • Confirmez que la demande de tirage est fermée.
  • Confirm no preview upload is running.
  • Switchez-vous de la prévisualisation active ou appelezresetPreview.
  • Attendez que ce changement d'état se termine.
  • Appelez Delete Preview uniquement ensuite.

N'attribuez pas une réponse HTTP réussie à la demande de réinitialisation comme preuve que l'application a déjà changé d'état sur chaque appareil. Un appareil peut vérifier les mises à jour plus tard. Votre nettoyage côté serveur peut toujours se poursuivre une fois que l'affectation de prévisualisation a été clairement supprimée selon la réponse API, mais gardez le comportement des appareils séparé de la suppression de ressources.

Capgo prend en charge le contrôle de la mise en production basé sur les canaux, ce qui rend cette séparation plus facile à raisonner. Un canal est un chemin nommé qui indique à une application quelle flux d'actualisation suivre. Votre canal de prévisualisation ne devrait jamais être le même canal utilisé par les appareils de production.

Pour les équipes qui nécessitent une frontière plus stricte, utilisez la documentation Capgo flux de canal pour l'automatisation de la prévisualisationIl décrit le modèle de canal temporaire et aide à garder un job de nettoyage à l'écart des canaux par défaut partagés.

La documentation de l'actualiseur open-source enregistre également la limite de suppression : les prévisualisations actives nécessitent un déplacement ou un redémarrage avant. Vous pouvez examiner le code source dans le Capgo Capacitor dépôt de l'actualiseur. Ce code est utile lorsque les mots de la page de tableau de bord sont trop courts pour une décision CI.

Conseil Pro : Effectuez un redémarrage séparé en tant que étape enregistrée. Si la suppression de la prévisualisation échoue, le journal doit montrer si la prévisualisation était toujours active ou si la demande de suppression avait un autre problème.

Une fois l'état actif disparu, le registre de la prévisualisation est prêt à la suppression. N'associez pas le redémarrage et la suppression en une seule ligne opaque. Deux commandes claires sont plus faciles à réessayer et beaucoup plus faciles à auditer.

Étape 4 : Supprimer les ensembles de prévisualisation par ID avec l’API Clé

Delete each preview bundle by its exact ID, after the active preview has been reset. This is where a Capgo cleanup key removes the storage objects left by the pull request.

Start with the bundle list from Step 2. For each matching ID, call the Delete Bundle action through the Capgo SDK or the current public API method available to your account.

Inspectez la signature de la méthode SDK ou confirmez la forme actuelle de la demande avec l'aide de Capgo. Enregistrez la méthode et le format de réponse dans le livre de route interne de votre équipe une fois que vous les avez vérifiés. Ce livre de route devrait inclure la version API, l'identifiant requis et les codes d'erreur que votre logique de réessai peut gérer.

Utilisez un mode de test en mode sec dans votre script. Il devrait imprimer le canal de prévisualisation et les identifiants de bundle qu'il supprimerait, sans envoyer de requêtes de suppression. Exécutez ce mode contre plusieurs demandes de tirage fermées. Vérifiez qu'il exclut les canaux de production et qu'il ne traite pas une liste vide comme un wild card.

Un boucle de suppression sûre comporte trois portes :

  1. Rejetez un identifiant de bundle manquant ou mal formé.
  2. Rejetez un bundle dont le canal ne correspond pas à la prévisualisation de la demande de tirage.
  3. Supprimez uniquement après que le contrôle d'appartenance passe.

Traitez ensuite chaque réponse par type. Une suppression réussie peut être enregistrée comme complète. Une réponse non trouvée peut être traitée comme déjà propre si le ressource est connue pour avoir été supprimée par une tentative antérieure. Les erreurs d'autorisation doivent faire fail le job et alerter le propriétaire. Les limites de taux doivent faire pause et réessayer avec un délai plafonné.

Ne réessayez pas tous les erreurs. Un mauvais ID ne deviendra pas valide après trois tentatives. Une erreur d'autorisation signifie généralement que le champ de la clé est incorrect. Réessayez uniquement les échecs transitoires, et fixez un temps de course maximum pour qu'un job de nettoyage coincé ne consomme pas votre file d'attente CI.

La suppression du bundle est séparée de la suppression de la prévisualisation. La suppression du canal de prévisualisation n'entraîne pas automatiquement la suppression de tous les bundles. Votre tâche doit conserver un résultat pour chaque ID, puis effectuer une requête de liste finale si l’API le supporte. Si un bundle reste, signalez l'ID et arrêtez plutôt que de faire une affirmation de réussite silencieuse.

Gardez les journaux de suppression libres de secrets. Il est acceptable de logger le numéro de demande de tirage, le nom de la prévisualisation, l'ID du bundle, le résultat de la demande et la date. N'oubliez jamais de logger la clé API, un en-tête d'autorisation ou un objet de demande complet qui pourrait inclure l'une d'elles.

Cette approche vous donne un traçage d'audit utile sans transformer le journal en un autre endroit où les informations de connexion peuvent se répandre. Cela rend également la suppression échouée facile à reprendre car la prochaine exécution peut ignorer les enregistrements déjà confirmés comme absents.

Step 5: Automate Cleanup When a Pull Request Closes

Run the cleanup job from the pull request close event, but add checks that prevent a late build from deleting a new preview.

Votre workflow doit recevoir le référentiel et le numéro de demande de tirage à partir du payload de l'événement. Reconstituez le nom du canal de prévisualisation à partir de ces valeurs. N'acceptez pas un nom de canal fourni par un commentaire de demande de tirage ou une variable de branch variable non fiable.

Une séquence de tâches utile ressemble à ceci :

  1. Chargez la clé de suppression restreinte à partir de secrets chiffrés.
  2. Confirmez que l'événement est une demande de tirage fermée.
  3. Vérifiez que la prévisualisation appartient au référentiel et à l'application attendus.
  4. Attendez que toute déploiement de prévisualisation active se termine.
  5. Passez à autre chose ou appelezresetPreview.
  6. List bundle IDs for that preview.
  7. Supprimez chaque bundle vérifié.
  8. Supprimez l’enregistrement de prévisualisation.
  9. Écrivez un résultat court dans la synthèse de workflow.

L’ordre compte. Si vous supprimez en premier, la règle de prévisualisation active peut bloquer la demande. Si vous sautez l’appel de liste, vous ne pourriez pas savoir quels identifiants de bundle existent encore. Si vous supprimez par un nom supposé, vous risquez de toucher la mauvaise ressource.

Automated CI/CD workflow for pull request preview cleanup

Utilisez une règle de concurrence cléée sur le numéro de demande de tirage. Lorsqu’un événement de fermeture et un événement de rebuild arrivent à peu près au même moment, l’ancien job de suppression ne doit pas courir le nouveau déploiement. Annulez une tâche de suppression obsolète ou faites attendre le job jusqu’à ce que le verrou de déploiement soit libéré.

Capgo’s workflow de commande unique CLI peut réduire le nombre de appels de shell personnalisés autour de la construction et de la mise en production. Pour les noms de commande et les opérations prises en charge, consultez la Capgo documentation de commande CLI. Utilisez le CLI où cela vous donne une commande vérifiée. Utilisez le SDK ou l’API public où les actions de suppression nécessitent une demande directe.

N’insérez pas la suppression dans un flux de travail qui s’exécute avec chaque push. Un job de push peut supprimer une prévisualisation qui est encore en cours de test. L’événement de fermeture est le déclencheur approprié pour la suppression normale. Ajoutez un flux de travail de déclenchement manuel pour la récupération lorsqu’un job échoue.

Fixez une valeur de retenue par défaut également. Si un événement de fermeture est manqué, un job planifié peut trouver des aperçus plus anciens que la fenêtre de test autorisée par votre équipe. Ce job nécessite des mesures de sécurité plus strictes que la normale fermeture de l'hook.

For GitHub Actions, maintenez les permissions étroites et passez uniquement les valeurs nécessaires par l'étape de nettoyage. La documentation actuelle des GitHub Actions d'intégration Capgo explique où le jeton est stocké et comment le flux de travail se connecte à Capgo.

À ce stade, vous devriez avoir un chemin automatisé qui réagit à la fermeture, attend les jobs concurrents, réinitialise l'état actif, liste les ID et supprime uniquement les ensembles de données ciblés. Cela est suffisamment rapide pour le développement quotidien sans rendre le nettoyage un balai aveugle.

Étape 6 : Vérifiez le nettoyage et protégez les déploiements contre la suppression accidentelle.

La vérification ferme le Capgo boucle de nettoyage des aperçus de demande de tirage de la version de tirage.

After the cleanup job runs, check the preview channel again. Confirm that it no longer appears as an active preview. Then check the bundle list for the same app and filter. The expected result is that the targeted bundle IDs are gone while production bundles remain.

Enregistrez ces valeurs dans le résumé de la tâche :

  • Enregistrez ces valeurs dans le résumé du job :
  • Nom du canal d'aperçu.
  • Commit SHA used for ownership checks.
  • ID des ensembles de données trouvés.
  • ID des ensembles de données supprimés.
  • Tous les ID qui ont retourné une erreur.

Utilisez un statut clair. "Nettoyé" signifie que tous les cibles vérifiées sont supprimées. "Déjà nettoyé" signifie que la ressource n'existait pas avant cette exécution. "Besoins de revue" signifie que l'une ou plusieurs vérifications ont échoué. N'attribuez pas une suppression partielle à un succès.

Ajoutez un garde de production dans code. Rejetez les noms de canal comme votre canal par défaut ou votre canal de mise en production. Rejetez également un bundle si son métadonnée ne correspond pas à l'application de prévisualisation. Le garde doit échouer fermé. Lorsque le script ne peut pas identifier la cible avec confiance, il doit s'arrêter.

Gardez le rollback séparé du nettoyage. Un rollback change le bundle que les appareils reçoivent. Le nettoyage supprime une ancienne ressource de prévisualisation. Si un test trouve un bug après la fermeture de la demande de tirage, vous pourriez avoir besoin du bundle pour l'investigation. Définissez une fenêtre de conservation courte au lieu de supprimer instantanément l'événement si votre équipe débogue souvent après la fusion.

Faites attention à trois modèles de failure courants :

  • Erreur de prévisualisation active : Réinitialiser ou passer à autre chose avant de réessayer Supprimer l'avance.
  • ID de bundle manquant : exécutez l'action de liste à nouveau plutôt que de deviner.
  • Erreur de permission : Révisez l'étendue de la clé, puis émettez une nouvelle clé si nécessaire.

Rotez la clé de nettoyage à un horaire défini par votre politique de sécurité, et rotez-l’immédiatement si elle apparaît dans un journal ou un commit. Une nouvelle clé doit être testée avant que l'ancienne ne soit révoquée, à moins que l'exposition nécessite une révocation immédiate.

La documentation manquante autour de la suppression mérite une mention dans votre revue de sécurité. Traitez les SDK et les conseils vérifiés Capgo comme source pour votre mise en œuvre, et gardez votre propre contrat de demande sous contrôle de version.

Rappel clé : Vérifiez la prévisualisation et la liste de bundles après suppression, bloque les cibles de production dans code, et signalez la suppression partielle comme un échec.

Une seule commande est utile uniquement lorsque les garde-fous sont clairs. Suivez la prévisualisation. Adoptez un nom de canal prévisible. Annulez les modifications de versionnement séparément. Ensuite, laissez le travail de suppression faire son petit travail sans toucher le trafic en direct.

FAQ

Peut-on supprimer une prévisualisation active Capgo ?

Non. Une prévisualisation active doit être déplacée d'abord, ou vous devez appeler resetPreviewAprès que l'état actif est clair, exécutez Supprimer la prévisualisation. Cette règle est le détail principal à retenir lors de la configuration d'une clé de suppression de prévisualisation Capgo de demande de tirage API dans CI.

Faut-il des identifiants de bundle pour nettoyer une Capgo prévision ?

Oui. L'action Supprimer le bundle de Capgo nécessite les identifiants de bundle, donc listez les bundles disponibles avant de les supprimer. Correspondez chaque ID au canal de prévisualisation et au commit avant d'envoyer une demande de suppression. N'édifiez jamais un ID à partir d'un nom de branche ou supposez que la suppression de la prévisualisation supprime également tous les bundles.

Quel type de clé API devrait utiliser CI pour la suppression de prévisualisation ?

Utilisez une clé de prévisualisation App restreinte pour la mise à jour de la prévisualisation, stockée dans le magasin de secrets chiffrés de votre fournisseur CI. Limitez la clé à l'application ou à l'étendue dont elle a besoin. Gardez-la séparée de la clé utilisée pour publier les mises à jour de production. Cela rend la Capgo tâche de mise à jour plus facile à examiner et plus sûre à mettre à jour.

Peut-on automatiser la mise à jour lorsque la demande de tirage se ferme ?

Yes. Trigger cleanup from the closed pull request event, then wait for active deployment jobs before resetting the preview. List the bundle IDs, delete verified matches, and confirm the result. Add concurrency controls so a late build cannot race the cleanup job.

Pourquoi ma tâche de mise à jour Capgo échoue-t-elle ?

Les causes habituelles sont une prévisualisation active, un identifiant de bundle manquant ou une clé sans l'étendue nécessaire. Réinitialisez la prévisualisation d'abord, répétez l'appel de liste, puis inspectez les autorisations de la clé. Puisque les détails de la demande peuvent varier en fonction de la version API ou SDK, confirmez la méthode actuelle et les paramètres avant de modifier le script.

Conclusion

Utilisez Capgo avec une clé de prévisualisation dédiée et un ordre de mise à jour strict : réinitialisez la prévisualisation active, listez ses identifiants de bundle, supprimez les bundles vérifiés, puis supprimez la prévisualisation. Commencez par une mise à jour sèche contre une demande de tirage fermée, confirmez la forme de la demande dans la version actuelle SDK, et ajoutez la garde de canal de production avant d'activer la mise à jour automatique.

Mises à jour instantanées pour les applications Capacitor

Lorsqu'une bug de couche web est en direct, expédiez la correction par Capgo au lieu d'attendre des jours pour l'approbation de la boutique d'applications. Les utilisateurs reçoivent la mise à jour en arrière-plan tandis que les modifications natives restent dans le chemin de revue normal.

Dernières actualités de notre Blog

Capgo vous offre les meilleures informations nécessaires pour créer une application mobile véritablement professionnelle.