Integrationen

Deploy auf VPS

Die GitHub Action Sitequest-Software/sitequest-deploy-vps-action macht ein atomares Release auf deinem VPS im Capistrano-Stil: Sie lädt ein Tarball hoch, entpackt es in ein nummeriertes Release-Verzeichnis und schaltet anschließend den current-Symlink um. Optional wird eine systemd-Unit neu gestartet.

Was es macht

  1. Packt source auf dem Runner.
  2. Lädt das Archiv über die Sitequest REST-API hoch.
  3. Entpackt es auf dem VPS nach <target-base>/releases/<run-id>/.
  4. Setzt optional den Eigentümer per chown auf owner.
  5. Schaltet <target-base>/current atomar auf das neue Release um.
  6. Startet auf Wunsch restart-service neu.
  7. Räumt alte Releases auf (gesteuert über keep-releases).

Inputs

Input Pflicht Default Beschreibung
api-key Ja — Sitequest API-Key mit dem Scope vps:manage.
vps-id Ja — ID des Ziel-VPS.
source Nein dist Lokales Verzeichnis, das deployt werden soll.
target-base Ja — Absoluter Basispfad auf dem VPS. Releases landen unter <target-base>/releases/<run-id>/, der Symlink unter <target-base>/current.
keep-releases Nein 5 Anzahl alter Releases, die für Rollbacks aufbewahrt werden (0 = unbegrenzt).
restart-service Nein — systemd-Unit, die nach dem Symlink-Wechsel neu gestartet wird (mehrere durch Komma getrennt).
owner Nein — user:group für chown des Releases nach dem Entpacken.
api-base Nein https://panel.site.quest API-Basis-URL überschreiben (z. B. für Staging).

Outputs

Output Beschreibung
release-path Absoluter Pfad des neuen Release-Verzeichnisses auf dem VPS.
bytes-uploaded Größe des hochgeladenen tar.gz-Archivs in Bytes.
duration-ms Gesamtdauer des Deploys in Millisekunden.

Beispiel-Workflow

name: Deploy to VPS

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm ci
      - run: npm run build

      - id: deploy
        uses: Sitequest-Software/sitequest-deploy-vps-action@v1
        with:
          api-key: ${{ secrets.SITEQUEST_API_KEY }}
          vps-id: ${{ vars.SITEQUEST_VPS_ID }}
          source: dist
          target-base: /var/www/myapp
          keep-releases: 5
          restart-service: myapp.service
          owner: www-data:www-data

      - run: echo "Deployed to ${{ steps.deploy.outputs.release-path }}"

Layout auf dem VPS

/var/www/myapp/
├── current → releases/9876543210/
└── releases/
    ├── 9876543210/   ← neuestes
    ├── 9876543200/
    └── 9876543190/

Richte Nginx, deine systemd-Unit oder deinen Reverse-Proxy auf <target-base>/current/ aus. Ein Rollback ist ein einfaches ln -sfn <previous> current von Hand – oder du startest einfach einen früheren Workflow neu.

Benötigter Scope

Der API-Key braucht den Scope vps:manage. Lege ihn im Dashboard unter API / MCP (im Profilmenü) an.

Siehe auch