Capgo Previsualizzazione Pulizia Richiesta di Pull API Chiave

Eliminare un'anteprima di richiesta di pull sembra essere un lavoro da un comando. Con CapgoC'è un piccolo problema: devi allontanarti da un'anteprima attiva prima di eliminarla, quindi rimuovere i suoi bundle per ID. Costruiremo un flusso di pulizia sicuro con una chiave API limitata, ricerca anteprima, gestione reset, eliminazione bundle e automazione CI.

Tavola dei Contenuti

• Passo 1: Crea una Chiave Capgo API Limitata per la Pulizia Anteprime
• Passo 2: Identifica l'Anteprima della Richiesta di Pull e i suoi ID Bundle
• Passo 3: Svuota l'Anteprima Attiva Prima della Pulizia
• Etapo 4: Elimina i bundle di anteprima per ID con la chiave API
• Etapo 5: Automatizza la pulizia quando un pull request viene chiuso
• Etapo 6: Verifica la pulizia e proteggi i rulli da cancellazioni accidentali
• FAQ
• Conclusioni

Etapo 1: Crea una chiave Capgo API limitata per la pulizia delle anteprime

La prima fase di un flusso di pulizia delle anteprime di un pull request Capgo consiste nel creare una chiave che possa eseguire solo il lavoro necessario dal tuo job di CI.

Non inserire una chiave di organizzazione ampia in un flusso di lavoro di pull request. Un pull request può provenire da una branca che non ha ancora guadagnato la fiducia. Il flusso di lavoro può anche stampare un comando o un valore di ambiente durante un esecuzione fallita. Una chiave ristretta limita i danni se accade.

In Capgo, inizia con una chiave di anteprima dell'applicazione per il lavoro di anteprima. La chiave dovrebbe essere legata allo scopo dell'app o dell'anteprima che il tuo job gestisce. Se il tuo team utilizza il controllo di accesso basato su ruoli, limita la chiave agli app selezionate anziché concedere l'accesso su tutta l'organizzazione. Capgo documenta le scelte delle chiavi di anteprima in API key settings for web app workflows.

Memorizza il segreto nel tuo provider di CI con segreti crittografati. Dàgli un nome che indichi cosa fa, ad esempio CAPGO_PREVIEW_CLEANUP_KEYNon collocarlo in un file di flusso di lavoro, in uno script shell, in un commento di pull request o in un log generato.

Passa la chiave al processo di pulizia tramite una variabile di ambiente. Il tuo script dovrebbe fallire quando la variabile manca. Un fallback silenzioso è pericoloso perché può trasformare un lavoro di pulizia in una richiesta senza autenticazione, o tentare un sviluppatore di inserire una chiave nella riga di comando.

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

Conserva questa chiave separata dalla chiave utilizzata per pubblicare bundle di produzione. Il lavoro di pubblicazione potrebbe dover caricare una versione. Il lavoro di pulizia ha bisogno solo di eliminare risorse di anteprima. Le chiavi separate rendono la revisione più facile e riducono la possibilità che un'azione di cancellazione raggiunga un canale di produzione.

Utilizza lo stesso segreto in un ambiente protetto quando possibile. Richiedi l'approvazione prima che un lavoro possa toccare canali condivisi. Per anteprime di pull request ordinarie, il lavoro dovrebbe funzionare su un canale temporaneo e nulla altro.

Ricordo Principale: Utilizza una chiave di anteprima dedicata, limita il suo ambito di applicazione e conserva la chiave in segreti CI crittografati.

Prima di procedere, testa la chiave contro un'azione di lettura innocua. Conferma che il lavoro può vedere l'applicazione destinata, ma non può accedere a un'applicazione non correlata o a un flusso di lavoro di produzione. I dettagli esatti della richiesta di pulizia non sono pubblicati completamente, quindi conserva il tuo primo test piccolo e ispeziona la guida di supporto SDK o Capgo prima di aggiungere chiamate di cancellazione.

Passo 2: Identifica l'anteprima di pull request e i suoi ID di bundle

Il Capgo chiave di pulizia della preview del pull request API è utile solo quando il tuo lavoro sa quali ID di anteprima e bundle possiede.

Usa una regola di denominazione stabile per i canali di anteprima. Un modello comune è il nome del repository più il numero della richiesta di pull. Il punto chiave è la coerenza. Il tuo lavoro di pulizia deve ricostruire lo stesso identificatore dopo che la richiesta di pull è stata chiusa.

Salva il nome del canale di anteprima quando viene creata l'anteprima. Puoi collocarlo nell'output del workflow, un controllo di richiesta di pull o una piccola porzione di metadati del lavoro. Non dipendere da un nome di visualizzazione che una persona potrebbe modificare nella dashboard.

Successivamente, elenca i pacchetti legati a quella anteprima. L'azione di cancellazione del pacchetto di Capgo richiede gli ID dei pacchetti. La documentazione di riferimento indica una chiamata di lista per recuperare tutti gli ID dei pacchetti disponibili prima della cancellazione. Tratta quella lista come fonte di verità. Non indovinare mai un ID da un nome di file, un hash di commit o un nome di ramo.

Filtra i record restituiti dal canale di anteprima o da un altro valore che il tuo workflow controlla. Poi conserva l'ID esatto del pacchetto per ogni corrispondenza. Se la lista è vuota, segnala la pulizia come completa. Un risultato vuoto non è un fallimento a meno che il tuo workflow non aspetti una anteprima esistente.

Ricorda anche il SHA del commit che ha prodotto ogni anteprima. Ciò ti dà un secondo controllo prima della cancellazione. Se il nome del canale corrisponde ma il commit non lo fa, fermati e chiedi una revisione. Quel piccolo ritardo può prevenire una gara dove una nuova anteprima viene costruita mentre un vecchio lavoro di pulizia esegue.

Non cancellare mentre è in esecuzione un lavoro di pubblicazione. Aggiungi una dipendenza tra la build di anteprima e i flussi di lavoro di pulizia, o utilizza un blocco legato al numero della richiesta di pull.

Capgo’s pubblica API copre risorse come canali e pacchetti attraverso richieste HTTP autenticate, ma le azioni di pulizia richiedono comunque una verifica accurata nel tuo progetto. Capgo pubblica API panoramica è il posto giusto per confermare il modello delle risorse corrente prima di scrivere un wrapper.

Dovresti avere già un identificatore di anteprima, una lista di ID di pacchetti esatti e il SHA del commit legato a ogni record. Se uno di questi valori manca, fermati qui. La pulizia senza controlli di proprietà è solo una congettura.

Passo 3: Passa da un'anteprima attiva prima della pulizia

Un'anteprima attiva non può essere cancellata fino a quando l'app non si sposta da essa o non chiamiresetPreviewQuesto è il dettaglio chiave nella Capgo flusso di pulizia anteprima della richiesta di pull.

Pensa all'anteprima attiva come alla versione attualmente selezionata dall'app. Cancellare il record server-side per primo lascerebbe l'app che punta a qualcosa che non esiste più. Capgo blocca questo stato di cambiamento, quindi il tuo lavoro di pulizia deve resettare lo stato di anteprima dell'app prima di rimuovere l'anteprima.

Prima, controlla se la preview è ancora attiva. Se lo è, sposta l'app in un canale sicuro o utilizza l'azione di reset dell'aggiornamento. La scelta giusta dipende da come è configurata la tua app di test. Un'app di test disimpegnabile può tornare al suo canale di default normale. Un'app di test condivisa potrebbe invece richiedere un canale di staging dedicato.

UsaresetPreviewquando lo stato di preview deve essere cancellato direttamente. Assicurati di legare questa chiamata alla stessa richiesta di pull e all'app che ha creato la preview. Un script di pulizia non dovrebbe mai resettare un dispositivo di produzione o un canale di rilascio condiviso solo perché il nome del canale corrisponde.

C'è una regola di ordinamento utile qui:

• Conferma che la richiesta di pull è chiusa.
• Confirm no preview upload is running.
• Sposta via dalla preview attiva o chiamaresetPreview.
• Aspetta che lo stato di cambio si sia completato.
• Chiamare Delete Preview solo allora.

Non trattare una risposta HTTP di successo dalla richiesta di reset come prova che l'app abbia già cambiato stato su ogni dispositivo. Un dispositivo potrebbe controllare gli aggiornamenti in un secondo momento. La tua pulizia server-side può procedere comunque una volta che l'assegnazione della preview è stata cancellata secondo il API risposta, ma mantieni il comportamento del dispositivo separato dalla cancellazione delle risorse.

Capgo supporta il controllo di rollout basato sui canali, il che rende questa separazione più facile da ragionare. Un canale è una via denominata che dice all'app quale flusso di aggiornamento seguire. Il tuo canale di preview non dovrebbe mai essere lo stesso canale utilizzato dai dispositivi di produzione.

Per le squadre che richiedono un confine più stretto, utilizza il documento flusso del canale Capgo per l'automazione della previewDescrive il modello temporaneo del canale e aiuta a tenere lontana la job di pulizia dai canali di default condivisi.

La documentazione dell'aggiornatore open-source registra anche il limite di cancellazione: le anteprime attive richiedono un passaggio via o un reset prima. Puoi esaminare la fonte nel repository dell'aggiornatore Capgo Capacitor. Quella fonte è utile quando le parole del dashboard sono troppo brevi per una decisione di CI.

Prova utile: Fai di reset un passo separato registrato. Se Elimina Anteprima fallisce, il log dovrebbe mostrare se l'anteprima era ancora attiva o se il richiesta di cancellazione aveva un altro problema.

Una volta che lo stato attivo è andato, il record dell'anteprima è pronto per la cancellazione. Non combinare reset e cancellazione in una riga di shell opaca. Due comandi chiari sono più facili da riprovare e molto più facili da auditare.

Passo 4: Elimina bundle di anteprima per ID con la chiave API

Elimina ogni bundle di anteprima per il suo ID esatto, dopo che l'anteprima attiva è stata resettata. È qui che una chiave di pulizia Capgo elimina gli oggetti di archiviazione lasciati dal pull request.

Inizia con l'elenco dei bundle da Step 2. Per ogni ID corrispondente, chiama l'azione Elimina Bundle attraverso il metodo Capgo SDK o il metodo pubblico attuale API disponibile al tuo account.

Esamina la firma del metodo SDK o conferma la forma attuale della richiesta con il supporto di Capgo. Registra il metodo e il formato di risposta nel tuo libro di runbook interno una volta verificati. Questo libro di runbook dovrebbe includere la versione API, l'identificatore richiesto e i codici di errore che la tua logica di riprova può gestire.

Utilizza un modo di prova secca nel tuo script. Dovrebbe stampare il canale di anteprima e gli ID del pacchetto che eliminerebbe, senza inviare richieste di cancellazione. Esegui quel modo contro diversi pull request chiusi. Verifica che escluda i canali di produzione e che non trattasse una lista vuota come un asterisco.

A safe deletion loop has three gates:

1. Rifiuta un ID di pacchetto mancante o malformato.
2. Rifiuta un pacchetto il cui canale non corrisponde alla anteprima del pull request.
3. Cancella solo dopo che il controllo di proprietà passa.

Poi gestisci ogni risposta per tipo. Una cancellazione riuscita può essere registrata come completa. Una risposta non trovata può essere trattata come già pulita se il risorsa è nota essere stata eliminata da un tentativo precedente. Gli errori di autorizzazione dovrebbero fallire il lavoro e avvertire il proprietario. I limiti di velocità dovrebbero sospendere e riprovare con un ritardo cappato.

Non riprovare ogni errore. Un ID sbagliato non diventerà valido dopo tre tentativi. Un errore di autorizzazione significa generalmente che lo scope della chiave è sbagliato. Riprova solo le fallite transitorie, e impostare un tempo di esecuzione massimo affinché un lavoro di pulizia bloccato non consumi la tua coda di CI.

La cancellazione del pacchetto è separata dalla cancellazione della anteprima. La rimozione del canale di anteprima non provoca automaticamente che ogni pacchetto sia andato. Il tuo lavoro dovrebbe mantenere un risultato per ogni ID, quindi fare una richiesta di lista finale se il API lo supporta. Se qualsiasi pacchetto rimane, segnalare l'ID e fermarsi piuttosto che dichiarare con successo senza emettere alcun segnale.

Tenere i log di cancellazione liberi da segreti. È tutto a posto per registrare il numero di richiesta di pull, il nome della anteprima, l'ID del pacchetto, il risultato della richiesta e la data. Mai registrare la chiave API, un'intestazione di autorizzazione o un oggetto di richiesta completo che potrebbe includere una.

Quell'approccio ti dà un utile tracciato di audit senza trasformare il log in un altro posto dove possono filtrare i credenziali. Ciò rende anche facile riprendere una pulizia fallita perché il prossimo run può saltare i record già confermati come assenti.

Passo 5: Automatizzare la pulizia quando un richiesta di pull viene chiusa

Eseguire il lavoro di pulizia dal evento di chiusura della richiesta di pull, ma aggiungere controlli per evitare che un costrutto tardivo cancelli una nuova anteprima.

La tua workflow dovrebbe ricevere il repository e il numero di richiesta di pull dall'oggetto di evento. Ricostruisci il nome del canale di anteprima da quei valori. Non accettare un nome di canale fornito da un commento di richiesta di pull o una variabile di ramo non fidata.

Una sequenza di lavoro utile assomiglia a questo:

1. Carica la chiave di pulizia limitata da segreti crittografati.
2. Conferma che l'evento è una richiesta di pull chiusa.
3. Verifica che l'anteprima appartenga al repository e all'app attesi.
4. Attendi che qualsiasi anteprima di deployment attiva si finisca.
5. Sposta via l'anteprima o chiamaresetPreview.
6. Elencare gli ID dei bundle per quella preview.
7. Eliminare ogni bundle verificato.
8. Eliminare il record della preview.
9. Scrivere un breve risultato nella sommario del workflow.

L'ordine conta. Se si elimina per primo, la regola di preview attiva può bloccare la richiesta. Se si salta la chiamata di lista, potreste non sapere quali ID dei bundle ancora esistono. Se si elimina con un nome ipotizzato, rischiate di toccare il risorsa sbagliata.

Usare una regola di concorrenza chiave al numero del pull request. Quando un evento di chiusura e un evento di rebuild arrivano vicini allo stesso tempo, il vecchio lavoro di pulizia non dovrebbe correre con la nuova distribuzione. Annullare un lavoro di pulizia obsoleto o far aspettare il lavoro fino a quando il blocco di distribuzione è libero.

Il flusso di lavoro di Capgo può ridurre il numero di chiamate di shell personalizzate intorno alla costruzione e alla distribuzione. Per i nomi dei comandi e le operazioni supportate, consultare la documentazione del comando Capgo CLI Capgo CLI documentazione del comandoUsa il CLI dove ti viene fornita una richiesta verificata. Usa il SDK o il API pubblico dove le azioni di pulizia richiedono una richiesta diretta.

__CAPGO_KEEP_0__’s flusso di lavoro di un comando __CAPGO_KEEP_1__ può ridurre il numero di chiamate di shell personalizzate intorno alla costruzione e alla distribuzione. Per i nomi dei comandi e le operazioni supportate, consultare la documentazione del comando __CAPGO_KEEP_0__ __CAPGO_KEEP_1__

Imposta un fallback di conservazione inoltre. Se un evento di chiusura viene perso, un lavoro programmato può trovare anteprime più vecchie del tuo team di test. Quel lavoro ha bisogno di misure di sicurezza più severe rispetto alla normale chiamata di chiusura. Dovrebbe selezionare solo anteprime con un proprietario chiaro e un timestamp scaduto.

Per GitHub Azioni, mantieni le autorizzazioni ristrette e passa solo i valori necessari dal passo di pulizia. La documentazione attuale delle GitHub Azioni di Capgo spiega dove il token è memorizzato e come il workflow si connette a Capgo.

Da adesso dovresti avere un percorso automatizzato che reagisce alla chiusura, attende i lavori concorrenti, resetta lo stato attivo, elenca gli ID e cancella solo i pacchetti corrispondenti. È abbastanza veloce per lo sviluppo quotidiano senza rendere la pulizia un rasoio di Occam.

Passo 6: Verifica la pulizia e proteggi i rilasci da cancellazioni accidentali

La verifica chiude il loop di pulizia della preview del pull request Capgo. Una sola risposta di cancellazione non è sufficiente per un processo di rilascio sicuro.

Dopo l'esecuzione del lavoro di pulizia, controlla nuovamente il canale delle anteprime. Assicurati che non appaia più come anteprima attiva. Poi controlla l'elenco dei pacchetti per la stessa app e filtro. Il risultato previsto è che gli ID dei pacchetti mirati siano andati mentre i pacchetti di produzione rimangono.

Salva questi valori nella sintesi del lavoro:

• Risorsa e numero di richiesta di pull.
• Nome del canale delle anteprime.
• Commit SHA used for ownership checks.
• Gli ID dei pacchetti trovati.
• Gli ID dei pacchetti cancellati.
• Qualsiasi ID che ha restituito un errore.

Usa uno stato chiaro. 'Pulito' significa che ogni target verificato è andato via. 'Già pulito' significa che il risorsa era assente prima di questa esecuzione. 'Da revisionare' significa che uno o più controlli sono falliti. Non etichetta una cancellazione parziale come successo.

Aggiungi un guardiano di produzione in code. Rifiuta i nomi dei canali come il tuo canale predefinito o di rilascio. Rifiuta anche un bundle se i suoi metadati non corrispondono all'app di anteprima. Il guardiano dovrebbe fallire chiuso. Quando lo script non può identificare il target con sicurezza, dovrebbe fermarsi.

Tenere separato il rollback dal pulito. Un rollback cambia quale bundle i dispositivi ricevono. Il pulito elimina una vecchia risorsa di anteprima. Se un test trova un bug dopo che la richiesta di pull si è chiusa, potresti aver bisogno del bundle per l'indagine. Imposta una finestra di conservazione breve al posto di eliminare immediatamente l'evento se il tuo team si occupa spesso di debug dopo il merge.

Guarda tre modelli di fallimento comuni:

• Errore di anteprima attiva: ripristina o passa via prima di riprovare Elimina Anteprima.
• ID bundle mancante: esegui l'azione di lista nuovamente al posto di indovinare.
• Errore di autorizzazione: revisiona lo scopo della chiave, quindi emetti una nuova chiave se necessario.

Rota la chiave di pulizia su un orario stabilito dalla tua politica di sicurezza, e rota la chiave immediatamente se appare in un log o in un commit. Una nuova chiave dovrebbe essere testata prima che l'antica venga revocata, a meno che l'esposizione richieda una revoca immediata.

La documentazione mancante intorno alla pulizia merita una nota nella tua revisione di sicurezza. Tratta la guida SDK e verificata Capgo come fonte per la tua implementazione, e mantieni il tuo proprio contratto di richiesta sotto controllo di versione.

Chiave di prelievo: Verifica la preview e la lista dei bundle dopo la cancellazione, blocca i target di produzione in code e segnala la pulizia parziale come fallita.

Un comando è utile solo quando i guardrail sono chiari. Traccia l'anteprima. Adotta un nome di canale prevedibile. Annulla le modifiche di rilascio separatamente. Poi lascia che il lavoro di pulizia faccia il suo piccolo lavoro senza toccare il traffico in tempo reale.

FAQ

Posso cancellare un'anteprima di richiesta di pull Capgo attiva?

No. L'anteprima attiva deve essere spostata via prima, o devi chiamare resetPreviewDopo che lo stato attivo si è spento, esegui Elimina anteprima. Questa regola è il dettaglio principale da ricordare quando si configura una chiave di pulizia Capgo per l'anteprima di richiesta di pull API in CI.

Devo avere gli ID dei bundle per pulire un'anteprima Capgo?

Sì. L'azione Elimina bundle di Capgo richiede gli ID dei bundle, quindi elenca i bundle disponibili prima di cancellarli. Corrispondi ogni ID al canale di anteprima e al commit prima di inviare una richiesta di cancellazione. Non costruisci mai un ID a partire da un nome di branch o supponi che la cancellazione dell'anteprima elimini tutti i bundle.

Di che tipo di chiave API dovrebbe utilizzare CI per la pulizia dell'anteprima?

Usa una chiave di anteprima App limitata per la pulizia del preview, memorizzata nel tuo provider di CI in un archivio segreto crittografato. Limita la chiave all'app o allo scopo necessario. Tienila separata dalla chiave utilizzata per pubblicare aggiornamenti di produzione. Ciò rende il Capgo lavoro di pulizia più facile da revisionare e più sicuro da rotare.

Posso automatizzare la pulizia quando un pull request viene chiuso?

Sì. Attiva la pulizia dall'evento di chiusura del pull request, poi attendi che le attività di deployment siano attive prima di resettare il preview. Elencare gli ID dei bundle, eliminare le corrispondenze verificate e confermare il risultato. Aggiungi controlli di concorrenza per evitare che un costrutto tardi possa correre il lavoro di pulizia.

Perché il mio Capgo richiesta di pulizia fallisce?

Gli motivi più comuni sono un preview attivo, un ID del bundle mancante o una chiave senza lo scopo necessario. Resetta il preview per primo, ripeti la chiamata di lista e ispeziona le autorizzazioni della chiave. Poiché i dettagli delle richieste possono variare a seconda della API o SDK versione, conferma il metodo e i parametri correnti prima di modificare lo script.

Conclusioni

Usa Capgo con una chiave di anteprima dedicata e un ordine di pulizia rigoroso: resettare il preview attivo, elencare gli ID dei bundle, eliminare i bundle verificati e poi eliminare il preview. Inizia con un run secco contro un pull request chiuso, conferma la forma della richiesta nella versione corrente SDK e aggiungi il guardiano del canale di produzione prima di attivare la pulizia automatica.