Vorschau-Bereitstellungen für Pull Requests

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…

Preview Deploys geben jedem Pull Request eine eigene Live-URL, die aus dem Code des Branches erstellt wird, damit Prüfer die eigentliche Änderung durchklicken können, statt ein Diff zu lesen und zu raten. Jede Preview wird aktualisiert, wenn du einen neuen Commit pushst, und wird automatisch bereinigt, wenn der Pull Request geschlossen wird.

Wo Preview Deploys zu finden sind

Öffne Websites, klicke auf die Website, öffne das Menü Environments in der Website-Tab-Leiste und wähle Preview. Die Seite trägt den Titel Preview deploys.

Previews sind von Staging getrennt. Staging ist eine lange, dauerhafte Kopie der Website, die du absichtlich pushst; eine Preview ist eine kurzlebige Umgebung, die pro Pull Request erstellt und danach verworfen wird. Viele Teams nutzen beide. Siehe Staging-Umgebungen für den anderen Teil.

Preview-Deploys-Seite in KPanel

Git Deploy zuerst einrichten

Previews sind kein eigenständiges Feature. Sie verwenden den Deploy-Schlüssel und Befehl der Produktionswebsite erneut, daher muss die Website eine funktionierende Git-Deploy-Konfiguration haben, bevor Previews aktiviert werden können.

Wenn Git Deploy nicht konfiguriert ist, zeigt die Seite Set up Git deploy first und bietet eine Schaltfläche Go to Git deploy statt des Aktivierungsformulars. Arbeite Deploying a Site From Git durch und komm dann zurück.

Wenn Git Deploy verbunden ist, aber keinen Build-Befehl hat, zeigt die Preview-Seite eine Warnung. Previews gehen davon aus, dass das Repository bereits erstellt wurde, mit statischen Dateien im Root-Verzeichnis. Das ist richtig für eine einfache HTML-Website und falsch für alles, das kompiliert wird. Stelle einen Build-Befehl auf der Git-Deploy-Seite ein, wenn dein Projekt einen benötigt.

Aktivieren von Previews

Gib im Enable preview deploys Feld das Repository in owner/repo Form ein. Keine URL, keine SSH-Adresse: nur die zwei Segmente, zum Beispiel acme/marketing-site.
Klicke auf Enable.

Alles, das nicht mit owner/name übereinstimmt, wird mit Repo must be in owner/name format abgelehnt.

Unmittelbar nach dem Aktivieren zeigt KPanel das Webhook-Signierungsgeheimnis in einer Karte mit dem Titel Copy your webhook secret now an, zusammen mit einer Warnung, dass du es später nicht wieder sehen wirst.

Kopiere das Geheimnis, bevor du die Seite verlässt. Es wird einmal generiert und kann danach nicht mehr abgerufen werden. Wenn du es verlierst, besteht die Lösung darin, es zu regenerieren, was das alte ungültig macht und bedeutet, dass du dein Repository-Webhook ohnehin aktualisieren musst.

Hinzufügen des Webhooks zu deinem Repository

Die konfigurierte Karte zeigt eine Webhook URL, die du in die Repository-Einstellungen unter Webhooks einfügen kannst. Konfiguriere es mit:

Payload URL: die auf der Seite angezeigte Webhook-URL.
Secret: der Wert, den du gerade kopiert hast.
Content type: JSON.
Events: Pull-Request-Events plus Pushes, damit neue Commits auf einem offenen Pull Request die Preview neu erstellen.

Wenn das eingerichtet ist, erstellt das Öffnen eines Pull Requests eine Preview innerhalb weniger Minuten. Ein Hintergrund-Job prüft jede Minute auf neue Preview-Arbeit, daher ist kein Drücken von irgendetwas in KPanel erforderlich.

Preview-URLs

Jede Preview erhält ihren eigenen Hostnamen der Form pr-<pull-request-number>-<site-id>.kapsulecloud.app, der durch ein Wildcard-Zertifikat gedeckt ist, damit er über HTTPS ohne eigene Zertifikatschritte bereitgestellt wird.

Die zuverlässige Methode, eine zu öffnen, ist die Schaltfläche Open in der Zeile der Preview in Recent previews, die die genaue URL trägt, die für diesen Build bereitgestellt wurde. Füge diesen Link in den Pull Request ein, damit Prüfer überhaupt nicht in KPanel schauen müssen.

Die Recent-Previews-Liste lesen

Der Abschnitt Recent previews listet die neuesten Previews auf, die neuesten zuerst. Jede Zeile zeigt die Pull-Request-Nummer und den Titel, den Branch, den Commit und einen Status:

Status	Bedeutung
BUILDING	Wird gerade geklont und erstellt
LIVE	Wird über seine Preview-URL bereitgestellt
FAILED	Der Build fehlgeschlagen; expandiere das Protokoll, um zu sehen, warum
DESTROYED	Bereinigt, normalerweise weil der Pull Request geschlossen wurde

Klicke auf Toggle build log in einer Zeile, um die Ausgabe des Builds inline zu expandieren. Dieses Protokoll ist der erste Ort, an dem man schauen sollte, wenn eine Preview fehlschlägt, und es ist dieselbe Ausgabe, die dein Build lokal produzieren würde.

Wenn die Liste leer ist, zeigt die Seite das an: Öffne einen Pull Request auf dem Repository und eine Preview wird innerhalb von Minuten erstellt.

Rotation des Webhook-Geheimnisses

Klicke auf Regenerate secret in der konfigurierten Karte. KPanel fordert dich auf, dies zu bestätigen, und macht deutlich, dass das aktuelle Geheimnis sofort nicht mehr funktioniert und du es danach in den Webhook-Einstellungen deines Repositorys aktualisieren musst.

Das neue Geheimnis wird einmal angezeigt, in derselben einmaligen Karte wie zuvor. Kopiere es und aktualisiere dann den Webhook in deinem Repository. Zwischen diesen beiden Momenten werden eingehende Webhook-Lieferungen abgelehnt, daher führe die beiden Schritte direkt nacheinander aus.

Regeneriere das Geheimnis, wenn jemand mit Repository-Admin-Zugriff geht, oder wenn das Geheimnis jemals an einen Ort kopiert wurde, wo es nicht sein sollte, wie zum Beispiel einen gemeinsamen Chat-Kanal oder ein Ticket.

Previews ausschalten

Klicke auf Disable. Die Konfiguration wird ausgeschaltet und das gespeicherte Geheimnis wird gelöscht. Existierende Previews werden nicht mehr neu erstellt.

Räume auf, indem du auch den Webhook in deinem Repository löschst. Er wird anfangen zu fehlschlagen, statt etwas Schädliches zu tun, aber ein Webhook, der ewig Fehler zurückgibt, ist Lärm im Lieferprotokoll deines Repositorys.

Kosten und Haushaltsführung

Previews erstellen und bedienen echten Code, daher nutzen sie die gleichen Ressourcen wie jede andere Bereitstellung auf der Website. Zwei Gewohnheiten halten das unter Kontrolle:

Schließe Pull Requests, an denen du nicht mehr arbeitest. Ein geschlossener Pull Request hat seine Preview automatisch bereinigt.
Weise Previews nicht auf Produktionsanmeldedaten hin. Gib ihnen Test-Keys über die Registerkarte Secrets unter preview Umgebung, die genau dafür da ist, dass Preview- und Produktionskonfiguration nicht verwechselt werden können.

Eine Preview-URL ist nicht privat. Es ist ein echter, öffentlich erreichbarer Hostname mit einem gültigen Zertifikat, und jeder, der den Link hat, kann ihn öffnen. Verwende eine Preview nicht zur Überprüfung von Inhalten mit echten Kundendaten, und seed Preview-Umgebungen nicht mit einem Produktionsdatenbank-Dump.

Fehlerbehebung

Nichts wird erstellt, wenn ein Pull Request geöffnet wird. Überprüfe die letzten Lieferungen des Webhooks in deinem Repository. Eine 401 oder 403 bedeutet, dass das Geheimnis nicht übereinstimmt, daher regeneriere es und aktualisiere beide Enden. Keine Lieferung überhaupt bedeutet, dass der Webhook nicht auf Pull-Request-Events abonniert ist.

Die Preview wird erstellt, zeigt aber ein Verzeichnislisting oder eine 404. Das Ausgabeverzeichnis auf der Git-Deploy-Seite stimmt nicht mit dem überein, wo dein Build tatsächlich schreibt. Previews erben diese Einstellung von der Produktion.

Der Build schlägt nur in der Preview fehl. Die häufigste Ursache ist eine Abhängigkeit oder eine Umgebungsvariable, die in der Produktion vorhanden ist, aber der Preview-Umgebung nie hinzugefügt wurde. Überprüfe die Registerkarte preview auf der Secrets-Seite.

Eine Preview-URL funktioniert nicht mehr. Schau auf den Status in ihrer Zeile. DESTROYED bedeutet, dass der Pull Request geschlossen wurde und die Umgebung zurückgefordert wurde, was das beabsichtigte Verhalten ist.

Wo es weiter geht

Deploying a Site From Git, die erforderliche Konfiguration.
Storing App Secrets For a Site für umgebungsspezifische Anmeldedaten.
Staging-Umgebungen für eine beständige Pre-Production-Kopie.