GitHub Actions: Workflows für Tests und Deployment

Kurz: GitHub Actions führt bei Ereignissen wie Push oder Pull Request automatisch Workflows aus: Tests, Linting, Builds und Deployments, definiert in YAML-Dateien im Repository.

Genauer: Mit GitHub Actions richtet man CI/CD direkt am Code ein. Ein Workflow (Datei unter .github/workflows/) wird durch Ereignisse ausgelöst und führt Jobs auf Runnern (virtuelle Rechner, GitHub-gehostet oder selbst betrieben) aus. Jeder Job besteht aus Schritten (Steps).

Im Detail

Ein Beispiel

name: CI
on:
  push:
    branches: [main]
  pull_request:
 
jobs:
  test:
    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 lint
      - run: npm test

uses: bindet fertige Actions ein (Marketplace), run: führt Befehle aus. Das Ergebnis erscheint im Pull Request als grüner Haken oder rotes Kreuz.

Wichtige Konzepte

• Trigger: push, pull_request, schedule (Cron), workflow_dispatch (manuell), release.
• Matrix: Tests auf mehreren Versionen/Systemen (strategy.matrix).
• Caching und Artefakte beschleunigen und speichern Ergebnisse.
• Secrets (${{ secrets.NAME }}) für Zugangsdaten, Variablen und Environments mit Freigabe (Genehmigung für Produktion).
• Abhängigkeiten zwischen Jobs (needs:), Bedingungen (if:).
• Wiederverwendbare Workflows und Composite Actions.

Sicherheit

• Minimale Rechte: permissions: am Workflow setzen (contents: read), Token nicht überberechtigen.
• Actions pinnen (auf Commit-SHA statt beweglichem Tag), vertrauenswürdige Quellen nutzen: Lieferkettenangriffe sind real.
• Secrets nie in Logs ausgeben; für Pull Requests aus Forks erhalten Workflows standardmäßig keine Secrets (richtig so).
• pull_request_target nur mit großer Vorsicht.
• Dependabot kann Action-Versionen aktuell halten.
• Eingaben (Branch-Namen, Titel) nicht ungeprüft in Shell-Befehle einsetzen (Injection).

Kosten und Grenzen

Für öffentliche Repositories sind Minuten kostenlos, für private gibt es ein Kontingent und danach Gebühren; ein Zahlungsproblem oder ein ausgeschöpftes Limit kann dazu führen, dass Jobs gar nicht starten. Plane schnelle Workflows, nutze Caches, begrenze Matrix und Laufzeit, und halte lokal reproduzierbare Befehle bereit (npm test), damit die CI nur dasselbe ausführt wie du lokal. Alternativen: GitLab CI, CircleCI, Jenkins, Forgejo/Gitea Actions.

Siehe auch: CI/CD-Pipeline, GitHub, Git-Hooks, Software-Lieferkette