Aus dem Quellcode bauen

Diese Seite ist für alle, die an Restow selbst arbeiten. Um Restow zu betreiben, installieren Sie die veröffentlichten Release-Images wie unter Erste Schritte beschrieben.

Voraussetzungen

Dieselben Anforderungen an den Host wie beim Release-Stack: Docker Engine mit dem Docker-Compose-Plugin. Node.js 22 und pnpm 9 brauchen Sie nur, um Restow zu entwickeln, nicht um den Quell-Stack zu betreiben.

Bauen und starten

Die docker-compose.yml des Repositorys baut beide Images aus dem Quellcode, statt sie zu laden. Holen Sie das Repository auf den Server, führen Sie cp .env.example .env aus, füllen Sie dieselben Werte wie beim Release-Stack aus (siehe Erste Schritte → Erforderliche Werte ausfüllen; lassen Sie RESTOW_IMAGE und RESTOW_WEB_IMAGE leer: Compose baut und startet dann restow:local und restow-web:local) und starten Sie den Stack:

docker compose up -d

Der erste Start baut die Images (Dockerfile-Target runtime für api/worker/scheduler, Target web für Caddy); das dauert einige Minuten. Der Quell-Stack bindet PostgreSQL an Loopback (POSTGRES_PORT, Standard 5432). Alles andere unter Erste Schritte gilt unverändert, auch das Setup-Token im ersten Schritt des Einrichtungsassistenten (docker compose logs api | grep 'SETUP TOKEN').

Zwei Build-Targets

Das Dockerfile baut die beiden Builds jedes Releases:

Build	Dockerfile-Targets	Release-Images	Enthält
Vollständig	runtime, web	ghcr.io/restow-backup/restow, ghcr.io/restow-backup/restow-web	Den Kern plus die Business- und Service-Provider-Module unter ee/, gesperrt, bis ein Lizenzschlüssel installiert ist.
Community	runtime-community, web-community	ghcr.io/restow-backup/restow-community, ghcr.io/restow-backup/restow-web-community	Nur den Apache-2.0-Kern. Der Build entfernt ee/, bevor etwas kompiliert wird, und bricht ab, wenn Code aus ee/ ins Image gelangt.

Der Quell-Stack baut die vollständigen Targets. Um den Community-Build aus einem Checkout zu betreiben, bauen Sie seine beiden Targets:

docker buildx build --target runtime-community -t restow-community:local --load .
docker buildx build --target web-community -t restow-web-community:local --load .

Setzen Sie dann RESTOW_IMAGE=restow-community:local und RESTOW_WEB_IMAGE=restow-web-community:local in .env und führen Sie docker compose up -d ohne --build aus. Die Details, auch die Prüfungen des Image-Inhalts, stehen in docs/CI.md („Two build targets“) im Repository.

Einen Quellcode-Checkout aktualisieren

Lesen Sie zuerst die Release-Notes, wie bei jedem Update. Dann:

git fetch --tags
git checkout vX.Y.Z
docker compose up -d --build

Verfolgen Sie dann die Migrationen und den Start mit docker compose logs -f api.

Hat der Updater jemals RESTOW_IMAGE und RESTOW_WEB_IMAGE in die .env geschrieben, bestimmen diese beiden Zeilen, welche Images die Dienste ausführen. Entfernen Sie sie, um wieder aus dem Checkout zu bauen. RESTOW_UPDATER_IMAGE gehört allein Ihnen: Der Updater schreibt die Zeile nie, und leer bedeutet, dass der Updater restow:local ausführt (bauen Sie es aus dem Release neu, auf das Sie wechseln).

Einen Quellcode-Checkout zurücksetzen

• Keine Migrationen im Release: Checken Sie die vorherige Version aus und führen Sie erneut docker compose up -d --build aus.

• Mit Migrationen: Migrationen lassen sich nicht zurückdrehen. Halten Sie den Stack an, spielen Sie die vor dem Update gemachte Datenbanksicherung zurück und starten Sie dann die vorherige Version:

  docker compose stop api worker scheduler
  docker compose exec -T postgres pg_restore -U restow -d restow --clean --if-exists < restow-YYYY-MM-DD.dump
  git checkout vPREVIOUS
  docker compose up -d --build

  Sicherungen, die nach dem Update entstanden sind, liegen im Chunk-Store, aber nicht in der zurückgespielten Datenbank, führen Sie daher nach dem Zurücksetzen ein Backup aus.

Mitwirken

Wie Beiträge funktionieren, beschreibt CONTRIBUTING.md im Repository.