Websites
Ein Projekt aus Git bereitstellen
Git Deploy connects a repository to a site so that every push to your chosen branch clones the code, runs your build, and publishes the result. This guide covers the initial connection, the two…
Git Deploy verbindet ein Repository mit einer Site, sodass jeder Push auf Ihren gewählten Branch den Code klont, Ihren Build ausführt und das Ergebnis veröffentlicht. Diese Anleitung behandelt die Erstverbindung, die zwei Repository-seitigen Schritte, die das Setup abschließen, das Lesen der Deploy-Verlauf und die Buildpack-Erkennung, die entscheidet, wie eine Node.js-App erstellt wird.
Wo sich Git Deploy befindet
Öffnen Sie Websites, klicken Sie auf die Site, öffnen Sie das Advanced-Menü in der Site-Tab-Leiste und wählen Sie Git Deploy. Zwei verwandte Seiten befinden sich im selben Menü:
- Deploys, der vollständige Deploy-Verlauf für diese Site.
- Buildpack, die erkannte Build-Strategie auf Node.js-Sites.
Die Git Deploy-Seite beschreibt sich selbst deutlich: Verbinden Sie ein Repository und jeder Push auf Ihren konfigurierten Branch löst einen Build und Deploy aus.
Ein Repository verbinden
- Wählen Sie Ihren Provider: GitHub, GitLab oder Bitbucket.
- Geben Sie die Repository-URL ein. Das SSH-Formular ist das, was Sie wollen, zum Beispiel
git@github.com:user/repo.git. - Legen Sie den Branch fest, aus dem bereitgestellt werden soll. Das Feld startet bei
main. - Legen Sie optional einen Build command fest, zum Beispiel
npm run build. - Legen Sie optional ein Output directory fest, zum Beispiel
dist,publicoder.für ein Repository, das bereits erstellt ist. - Klicken Sie auf Connect repo.
Lassen Sie den Build command und das Output directory leer, wenn Ihr Repository bereits so bereitgestellt werden kann, wie es ist. Dies ist der häufige Fall für eine einfache PHP- oder statische Site.
Advanced Scripts
Das Erweitern von Advanced zeigt zwei zusätzliche Felder:
- Pre-deploy script, das vor dem Build ausgeführt wird.
- Post-deploy script, das nach dem Deploy ausgeführt wird.
Verwenden Sie den Post-Deploy-Hook für Dinge, die passieren müssen, sobald neuer Code vorhanden ist: Löschen eines Anwendungs-Cache, Ausführung einer Datenbankmigration, Neustarten eines Worker.
Auto-Deploy bei Push
Das Umschalter am unteren Rand der Karte steuert, ob Pushes überhaupt bereitgestellt werden. Wenn es an ist, löst jeder Push auf dem konfigurierten Branch einen Deploy aus. Wenn es aus ist, werden Deploys nur ausgeführt, wenn Sie diese manuell mit Deploy now auslösen.
Deaktivieren Sie Auto-Deploy während einer Code-Einfrierung oder eines Incidents, anstatt das Repository zu trennen. Das Trennen wirft den Deploy-Schlüssel und das Webhook-Secret weg, sodass Sie beide Repository-seitigen Schritte danach wiederholen müssen.
Setup im Repository abschließen
Das Verbinden des Repository in KPanel ist nur der erste von drei Schritten. Bis ein Deploy ausgeführt wurde, zeigt die Seite ein Banner mit der Aufschrift Complete setup: 2 steps remaining mit allem, was Sie benötigen.
Schritt 2: Den Deploy-Schlüssel hinzufügen
Kapsule benötigt Lesezugriff, um Ihr Repository zu klonen. Das Banner zeigt einen öffentlichen Schlüssel mit einer Copy key-Schaltfläche.
Fügen Sie ihn in die Deploy-Schlüssel Ihres Repository ein. Für GitHub bietet das Banner eine Add to GitHub-Verknüpfung direkt zur richtigen Einstellungsseite. Lesezugriff ist ausreichend; gewähren Sie keinen Schreibzugriff.
Schritt 3: Den Webhook hinzufügen
Der Webhook teilt Kapsule mit, dass ein Push stattgefunden hat. Das Banner gibt Ihnen drei Werte:
| Feld | Wert |
|---|---|
| Payload URL | Eine URL, die mit /api/git-deploy/webhook/ endet, plus die ID dieser Site |
| Secret | Ein generiertes Signaturgeheimnis, verborgen bis Sie auf das Augensymbol klicken |
| Content Type | application/json |
Kopieren Sie jeden Wert in die Webhook-Einstellungen Ihres Repository. Für GitHub gibt es eine Add webhook to GitHub-Verknüpfung. Legen Sie den Content Type auf JSON fest, nicht auf die standardmäßig kodierte Form, oder die Payload wird nicht analysiert.
Behandeln Sie das Webhook-Secret wie ein Passwort. Jeder, der es plus die Payload-URL hat, kann einen Deploy Ihrer Site auslösen. Beide Werte werden nur Personen angezeigt, die die Site bereits verwalten können, und das Secret bleibt hinter dem Augensymbol verborgen, bis Sie danach fragen.
Manuelle Bereitstellung
Klicken Sie auf der Git Deploy-Seite auf Deploy now, um den aktuellen HEAD des konfigurierten Branch zu erstellen und bereitzustellen, ohne einen Commit zu pushen. Dies funktioniert unabhängig davon, ob Auto-Deploy aktiviert ist oder nicht. Das ist das richtige Werkzeug während einer Einfrierung: Pushes werden ignoriert, aber Sie können den Fix immer noch versenden.
Deploy-Verlauf lesen
Öffnen Sie Advanced, dann Deploys. Die Seite heißt Deploy history und listet jeden Deployment, der durch Webhook oder manuell ausgelöst wurde, mit dem neuesten zuerst.
Jede Zeile enthält:
- Ein Statussymbol und die kurze Commit-SHA mit dem Branch als Pill.
- Die Commit-Nachricht oder Manual deploy, wenn keine Commit-Nachricht angezeigt werden kann.
- Der Autor, wie lange es her ist, wie lange es gedauert hat und was es ausgelöst hat.
- Eine Status-Pill.
Die Status sind pending, building, deploying, success und failed. Während etwas im Gange ist, aktualisiert sich die Seite alle fünf Sekunden selbst und zeigt unter der Tabelle einen Refreshing automatically-Hinweis an, sodass Sie sie offen lassen und einen Deploy landen sehen können.
Wenn ein Deploy fehlschlägt
Eine fehlgeschlagene Zeile erhält auf der rechten Seite eine Error-Schaltfläche. Klicken Sie darauf, um die erfasste Fehlerausgabe inline zu erweitern, ohne die Seite zu verlassen. Diese Ausgabe ist der eigene Fehlertext des Builds, daher nennt er normalerweise die Datei oder den Befehl, der fehlgeschlagen ist.
Arbeiten Sie es in dieser Reihenfolge durch: Lesen Sie den Fehler, reproduzieren Sie denselben Build command lokal, beheben Sie ihn und pushen Sie ihn. Wenn der Build lokal funktioniert, aber nicht hier, ist der Unterschied fast immer ein Umgebungseins, eine fehlende Abhängigkeit, die auf Ihrem Computer global installiert ist, oder eine Datei, die sich in Ihrem Arbeitsverzeichnis befindet, aber nicht committed wurde.
Buildpack-Erkennung
Auf Node.js-Sites zeigt die Buildpack-Seite im Advanced-Menü, wie Kapsule entschieden hat, Ihre App zu erstellen. Die Erkennung läuft über die Dateien im Root Ihres Repository, und das erste Match gewinnt:
| Erkannt | Auslöser |
|---|---|
| Custom buildpack | kapsule.config.yaml oder kapsule.config.yml im Root |
| Dockerfile buildpack | Dockerfile im Root |
| Node.js | package.json mit einem start, build oder dev Script |
| Python | requirements.txt oder pyproject.toml |
| PHP | composer.json |
| Static | index.html im Root |
Wenn nichts übereinstimmt, sagt die Seite dies und listet die unterstützten Auslöser auf. Fügen Sie ein Dockerfile oder ein kapsule.config.yaml hinzu, um den Build explizit zu steuern.
Einen Build ausführen
Klicken Sie auf Run build, um einen in die Warteschlange einzureihen. Die Seite pollt alle drei Sekunden während eines Laufs, und die Tabelle Recent builds zeigt die letzten Läufe mit ihrer Startzeit, ihrem Typ, ihrem Status, ihrer Dauer und der resultierenden Image-Referenz. Klicken Sie auf eine Zeile, um das Protokoll-Tail anzuzeigen.
Nur ein Build kann gleichzeitig in Betrieb sein. Das Auslösen eines zweiten während einer Warteschlange oder eines laufenden wird mit A build is already in progress abgelehnt, was beabsichtigt ist: Zwei Builds, die gleichzeitig auf die gleiche Ausgabe schreiben, führen dazu, dass eine halb bereitgestellte Site entsteht.
Trennen
Klicken Sie auf Disconnect und bestätigen Sie. Die Bestätigung ist explizit zum Explosionsradius: Die Git Deploy-Konfiguration und der Deploy-Schlüssel werden entfernt, und Ihre Site-Dateien sind nicht betroffen. Die Site dient weiterhin das, was zuletzt bereitgestellt wurde.
Räumen Sie danach auf, indem Sie den Deploy-Schlüssel und den Webhook in Ihren Repository-Einstellungen löschen. Sie funktionieren einfach nicht mehr, aber das Hinterlassen von toten Einträgen macht die nächste Audit schwieriger.
Fehlerbehebung
Pushes lösen nichts aus. Überprüfen Sie zuerst den Auto-Deploy-Umschalter, dann den Webhook in Ihrem Repository. Die meisten Provider zeigen die letzten Lieferungen und ihre Response-Codes an, was Ihnen sofort sagt, ob die Anfrage Ihr Repository überhaupt verlassen hat.
Das Klonen schlägt fehl. Der Deploy-Schlüssel fehlt, wurde mit einem Zeilenumbruch eingefügt oder wurde zum falschen Repository hinzugefügt. Kopieren Sie ihn erneut mit der Copy key-Schaltfläche, anstatt den Text von Hand auszuwählen.
Der Deploy ist erfolgreich, aber die Site ändert sich nicht. Das Output directory ist wahrscheinlich falsch. Wenn Ihr Build in dist schreibt und das Output directory leer ist, erreichen die erstellten Dateien nie die Root mit served.
Alles sagt pending und bewegt sich nie. Der Deploy wurde in die Warteschlange eingereiht, wurde aber nie aufgegriffen. Lösen Sie einen manuellen Deploy now aus und überprüfen Sie die Deploys-Seite auf eine Fehlerzeile.
Wo es danach geht
- Preview Deploys For Pull Requests fügt zusätzlich zu diesem Setup eine URL pro PR hinzu.
- Storing App Secrets For a Site für die Anmeldeinformationen, die Ihr Build und Runtime benötigen.
- Site Activity Log protokolliert hier vorgenommene Konfigurationsänderungen.