Astro für Anfänger · Teil 31TutorialEinsteiger

Astro

Astro-Kurs 31: Automatisches Deployment mit GitHub Actions

Lerne automatisches deployment mit github actions mit praktischen Beispielen im Astro-Projekt Meine Modellbau-Werkstatt.

Veröffentlicht am

Modul 6 – Veröffentlichen und pflegen · Astro-Anfängerkurs der Know-How-Schmiede

Voraussetzung: Etappe 1 und 2 des Kurses. Das Beispielprojekt „Meine Modellbau-Werkstatt“ wird fortgeführt. Kopiere Code nicht blind über schon vorhandene Seiten, sondern ergänze bestehende Bereiche.

Lernziele

Du verstehst, wie GitHub nach einem Push automatisch den Astro-Build erstellt und ihn auf Webspace hochlädt. Du legst Zugangsdaten sicher als Secrets ab.

1. Vorbereitungen

Du benötigst ein Repository mit package-lock.json, einen bereits manuell getesteten Build und einen vom Hostinganbieter bereitgestellten SFTP-Zugang mit eingeschränkten Rechten. Der folgende Workflow nutzt einen SSH-Schlüssel und rsync über SSH. Er setzt voraus, dass dein Tarif SSH/SFTP und rsync auf der Serverseite unterstützt. Prüfe diese Voraussetzung vorher. Hostinger-Tarife unterscheiden sich; sonst ist ein anderer, passender Upload-Weg nötig.

2. Secrets einrichten

Gehe im GitHub-Repository zu Settings → Secrets and variables → Actions und hinterlege:

  • DEPLOY_HOST: Hostname des SSH-Servers
  • DEPLOY_USER: eingeschränkter Upload-Nutzer
  • DEPLOY_SSH_KEY: privater Deploy-Schlüssel (nur GitHub Secret)
  • DEPLOY_KNOWN_HOSTS: verifizierte known_hosts-Zeile für den Host
  • DEPLOY_PATH: absoluter Pfad zum Webroot (z. B. dem public_html der Testseite)

Den öffentlichen Schlüssel richtest du serverseitig ein. Host-Schlüssel-Fingerprint über einen unabhängigen, vertrauenswürdigen Weg verifizieren; StrictHostKeyChecking niemals einfach abschalten.

3. Workflow-Datei

Lege .github/workflows/deploy.yml an:

name: Astro deploy
on:
  push:
    branches: [main]
  workflow_dispatch:
permissions:
  contents: read
concurrency:
  group: website-deploy
  cancel-in-progress: false
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: npm
      - run: npm ci
      - run: npm run build
      - name: SSH vorbereiten
        env:
          SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }}
          SSH_HOST_KEYS: ${{ secrets.DEPLOY_KNOWN_HOSTS }}
        run: |
          mkdir -p ~/.ssh
          chmod 700 ~/.ssh
          printf '%s
' "$SSH_KEY" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519
          printf '%s
' "$SSH_HOST_KEYS" > ~/.ssh/known_hosts
          chmod 600 ~/.ssh/known_hosts
      - name: Upload
        env:
          HOST: ${{ secrets.DEPLOY_HOST }}
          USER: ${{ secrets.DEPLOY_USER }}
          PATH_REMOTE: ${{ secrets.DEPLOY_PATH }}
        run: |
          rsync -az --exclude='.well-known/' -e 'ssh -i ~/.ssh/id_ed25519 -o StrictHostKeyChecking=yes' dist/ "$USER@$HOST:$PATH_REMOTE/"

Wichtig: Der Workflow verwendet absichtlich kein --delete. Er entfernt also keine veralteten Dateien. Für eine spätere Bereinigung unbedingt vorher Sicherungen und Regeln für fremde Verzeichnisse festlegen. Für öffentliche Produktion empfiehlt es sich außerdem, GitHub Actions auf konkrete, geprüfte Commit-SHAs festzulegen.

4. Testen

Führe zunächst einen Push in ein Test-Repository bzw. auf eine Test-Webseite durch. Öffne in GitHub die Registerkarte Actions und prüfe, ob Build und Upload erfolgreich waren. Danach Browserprüfung durchführen.

Übung

Erkläre in eigenen Worten, warum DEPLOY_SSH_KEY nicht in deploy.yml stehen darf.

Lösungshinweis

Ein privater Schlüssel im Repository wäre allen mit Lesezugriff und möglicherweise später auch in der Commit-Historie zugänglich. GitHub Secrets vermeiden eine direkte Speicherung im Quellcode (sie ersetzen aber keine sorgfältige Rechtevergabe).

---