Statische Anwendung aus Git bereitstellen

Bereits gebaute Dateien aus einem öffentlichen Git-Repository als unveränderliche Version veröffentlichen.

Mit Git Deploy übernimmt obhut bereits gebaute statische Dateien aus einem öffentlichen HTTPS-Repository. Jede erfolgreiche Bereitstellung erzeugt eine unveränderliche Version auf beiden privaten Origins. Erst eine separate Aktivierung schaltet diese Version für den öffentlichen Hostname frei.

Kein Build-Dienst

obhut führt keine Build-, Paketmanager-, Installations- oder anderen Repository-Befehle aus. Das konfigurierte Ausgabeverzeichnis muss vollständig im ausgewählten Branch eingecheckt sein.

Voraussetzungen

Eine Anwendung mit statischer Bereitstellung im obhut-Dashboard.
Ein öffentlich erreichbares Git-Repository mit kanonischer HTTPS-URL.
Ein Branch mit den bereits gebauten Ausgabedateien.
Die Rolle Eigentümer oder Admin für Konfiguration, Bereitstellung und Aktivierung. Leserollen können Konfiguration und Status einsehen.

Private Repository-Zugangsdaten, SSH-URLs, Submodule und Git LFS werden nicht unterstützt. Das Dashboard zeigt ausdrücklich an, wenn Git-Bereitstellungen in der gewählten Umgebung noch nicht freigeschaltet sind; in diesem Zustand nimmt die API keine Jobs an.

Quelle konfigurieren

Statische Versionen öffnen

Öffne die statische Anwendung und wechsle in den Bereich Versionen.

Repository und Branch eintragen

Trage die öffentliche HTTPS-URL, zum Beispiel https://github.com/organisation/webseite.git, und den gewünschten Branch ein.

Ausgabeverzeichnis festlegen

Verwende einen relativen Pfad wie dist oder public. Liegen die fertigen Dateien direkt im Repository-Wurzelverzeichnis, verwende ..

Quelle speichern

Speichere die Quelle. Diese Konfiguration führt noch keine Bereitstellung aus und verändert keine aktive Version.

Manuell bereitstellen und aktivieren

Wähle Jetzt bereitstellen. obhut lädt den Branch über den isolierten Fetch-Pfad und veröffentlicht nur das konfigurierte Ausgabeverzeichnis.
Beobachte im Dashboard die Phasen Eingereiht, Repository wird geladen und Artefakt wird veröffentlicht.
Prüfe bei Status Bereit den aufgelösten Commit und den SHA-256-Digest des Artefakts.
Wähle Version aktivieren und bestätige den separaten Wechsel.

Ein fehlgeschlagener oder abgebrochener Job kann als neue Bereitstellung erneut gestartet werden. Jobs in der Warteschlange oder beim Laden lassen sich abbrechen. Sobald die Veröffentlichung auf die beiden Origins begonnen hat, wird sie atomar abgeschlossen oder als fehlgeschlagen markiert.

Rollback

Die bisherige aktive Version bleibt als unveränderliche, bereite Version erhalten. Für einen Rollback wählst du sie in der normalen Versionsliste aus und aktivierst sie erneut. Dabei wird nur der aktive Zeiger atomar gewechselt; es wird weder neu gebaut noch erneut aus dem Repository geladen.

Stabiles Routing

Bereitstellung, Aktivierung, Wiederholung und Rollback verwenden die bereits eingerichtete Anwendung. Für Tests oder einzelne Versionen sind keine DNS-Änderungen erforderlich.

Unterstützte Grenzen

Git Deploy ist bewusst auf öffentliche, vorgebaute statische Inhalte begrenzt:

nur öffentliche HTTPS-Repositories;
genau ein Branch und ein relatives Ausgabeverzeichnis je Quelle;
keine privaten Tokens oder SSH-Schlüssel;
keine Builds, Paketmanager oder Installationsskripte;
keine Submodule und kein Git LFS;
dieselben Größen-, Datei- und Replikationsgrenzen wie beim direkten tar.gz-Upload.

Diese Grenzen halten fremden Build-Code und langlebige Repository-Zugangsdaten aus der obhut-Control-Plane heraus.