Siti web
Anteprima dei Deploy per Pull Request
Preview deploys give every pull request its own live URL, built from that branch's code, so reviewers can click through the actual change instead of reading a diff and guessing. Each preview updates…
I preview deploy danno a ogni pull request il suo URL live personale, costruito dal codice di quel ramo, in modo che i revisori possono cliccare attraverso il cambio effettivo invece di leggere un diff e indovinare. Ogni preview si aggiorna quando effettui il push di un nuovo commit e viene pulito automaticamente quando la pull request si chiude.
Dove vivono i Preview Deploy
Apri Websites, clicca il sito, apri il menu Environments nella barra delle schede del sito, e scegli Preview. La pagina è intitolata Preview deploys.
I preview sono separati dallo staging. Staging è una singola copia longeva del sito che effettui il push deliberatamente; un preview è un ambiente breve creato per pull request e buttato via dopo. Molti team usano entrambi. Vedi Staging Environments per l'altra metà.
Configura Git Deploy per primo
I preview non sono una funzione standalone. Riutilizzano la chiave di deploy e il comando di build del sito di produzione, quindi il sito ha bisogno di una configurazione Git Deploy funzionante prima che i preview possano essere abilitati.
Se Git Deploy non è configurato, la pagina dice Set up Git deploy first e offre un pulsante Go to Git deploy piuttosto che il modulo di abilitazione. Lavora attraverso Deploying a Site From Git, poi torna indietro.
Se Git Deploy è connesso ma non ha un comando di build, la pagina Preview mostra un avviso. I preview assumeranno che il repository sia già compilato, con file statici nella radice. Questo è corretto per un sito HTML puro e sbagliato per qualsiasi cosa che compila, quindi imposta un comando di build nella pagina Git Deploy se il tuo progetto ne ha bisogno.
Abilitazione dei Preview
- Nella scheda Enable preview deploys, digita il repository in forma
owner/repo. Non un URL, non un indirizzo SSH: solo i due segmenti, ad esempioacme/marketing-site. - Clicca Enable.
Qualsiasi cosa che non corrisponda a owner/name viene rifiutata con Repo must be in owner/name format.
Immediatamente dopo l'abilitazione, KPanel mostra il segreto di firma del webhook in una scheda intitolata Copy your webhook secret now, con un avviso che non lo vedrai di nuovo.
Copia il segreto prima di lasciare la pagina. Viene generato una volta e non è recuperabile dopo. Se lo perdi, la soluzione è rigenerarlo, il che invalida quello vecchio e significa aggiornare comunque il webhook del tuo repository.
Aggiunta del Webhook al tuo Repository
La scheda configurata mostra un Webhook URL da incollare nelle impostazioni del tuo repository, sotto Webhooks. Configuralo con:
- Payload URL: l'URL del webhook mostrato sulla pagina.
- Secret: il valore che hai appena copiato.
- Content type: JSON.
- Events: pull request events, più push, in modo che i nuovi commit su una pull request aperta ricostruiscano il preview.
Una volta fatto questo, aprire una pull request costruisce un preview entro pochi minuti. Un lavoro in background controlla il nuovo lavoro di preview ogni minuto, quindi non c'è bisogno di premere nulla in KPanel.
URL dei Preview
Ogni preview riceve il suo hostname nella forma pr-<pull-request-number>-<site-id>.kapsulecloud.app, coperto da un certificato wildcard in modo che sia servito su HTTPS senza una fase di certificato tua.
Il modo affidabile per aprirne uno è il pulsante Open sulla riga del preview in Recent previews, che contiene l'URL esatto che è stato fornito per quella build. Incolla quel link nella pull request in modo che i revisori non debbano trovare KPanel affatto.
Lettura dell'elenco dei Preview Recenti
La sezione Recent previews elenca i preview più recenti, i più nuovi per primi. Ogni riga mostra il numero della pull request e il titolo, il ramo, il commit e uno stato:
| Status | Meaning |
|---|---|
| BUILDING | Clonazione e compilazione in corso |
| LIVE | Servito dal suo URL di preview |
| FAILED | La compilazione ha dato errore; espandi il log per scoprire perché |
| DESTROYED | Pulito, di solito perché la pull request si è chiusa |
Clicca Toggle build log su una riga per espandere il suo output di compilazione inline. Quel log è il primo posto dove guardare quando un preview fallisce, ed è lo stesso output che la tua compilazione produrrebbe localmente.
Se l'elenco è vuoto, la pagina lo dice: apri una pull request sul repository e un preview sarà costruito entro minuti.
Rotazione del Segreto del Webhook
Clicca Regenerate secret nella scheda configurata. KPanel ti chiede di confermare, ed è esplicito sul fatto che il segreto attuale smette di funzionare immediatamente e dovrai aggiornarlo nelle impostazioni del webhook del tuo repository dopo.
Il nuovo segreto viene mostrato una volta, nella stessa scheda monouso di prima. Copialo, poi aggiorna il webhook nel tuo repository. Tra quei due momenti, le consegne dei webhook in arrivo vengono rifiutate, quindi fai i due passaggi uno dopo l'altro.
Rigenera il segreto quando qualcuno con accesso admin del repository se ne va, o se il segreto è mai stato incollato da qualche parte non dovrebbe essere, come un canale di chat condiviso o un ticket.
Disattivazione dei Preview
Clicca Disable. La configurazione viene disattivata e il segreto memorizzato viene cancellato. I preview esistenti smettono di essere ricostruiti.
Pulizia completando l'eliminazione del webhook nel tuo repository. Inizierà a fallire piuttosto che fare qualcosa di dannoso, ma un webhook che ritorna errori per sempre è rumore nel log di consegna del tuo repository.
Costi e Manutenzione
I preview costruiscono e servono codice reale, quindi usano le stesse risorse di qualsiasi altro deploy sul sito. Due abitudini mantengono tutto sotto controllo:
- Chiudi pull request su cui non stai più lavorando. Una pull request chiusa ha il suo preview pulito automaticamente.
- Non puntare i preview a credenziali di produzione. Dagli chiavi di test attraverso la scheda Secrets dell'ambiente preview, che esiste precisamente affinché la configurazione di preview e produzione non possano essere confuse.
Un URL di preview non è privato. È un hostname reale, pubblicamente raggiungibile, con un certificato valido, e chiunque abbia il link può aprirlo. Non usare un preview per revisionare qualsiasi cosa contenente dati di clienti reali, e non seminare ambienti di preview da un dump di database di produzione.
Troubleshooting
Nulla è costruito quando viene aperta una pull request. Controlla le consegne recenti del webhook nel tuo repository. Un 401 o 403 significa che il segreto non corrisponde, quindi rigeneralo e aggiorna entrambi gli estremi. Nessuna consegna affatto significa che il webhook non è iscritto agli eventi di pull request.
Il preview si costruisce ma mostra un elenco di directory o un 404. La directory di output nella pagina Git Deploy non corrisponde a dove la tua compilazione effettivamente scrive. I preview ereditano quell'impostazione dalla produzione.
La compilazione fallisce solo nel preview. La causa più comune è una dipendenza o una variabile di ambiente che esiste in produzione ma non è mai stata aggiunta all'ambiente di preview. Controlla la scheda preview nella pagina Secrets.
Un URL di preview smette di funzionare. Guarda lo stato nella sua riga. DESTROYED significa che la pull request si è chiusa e l'ambiente è stato recuperato, che è il comportamento previsto.
Dove andare dopo
- Deploying a Site From Git, la configurazione prerequisito.
- Storing App Secrets For a Site per credenziali per-ambiente.
- Staging Environments per una copia pre-produzione persistente.