GitHub Actions: Deine erste Pipeline

Im letzten Beitrag hast du die Theorie hinter CI/CD kennengelernt. Jetzt wird es praktisch: Mit GitHub Actions baust du deine erste Pipeline – direkt in deinem Repository, ohne externe Dienste. In diesem Beitrag erstellst du Schritt für Schritt eine Workflow-Datei, die deinen Code automatisch baut und testet.

Was sind GitHub Actions?

GitHub Actions ist das eingebaute CI/CD-System von GitHub. Du beschreibst deine Pipeline in einer YAML-Datei, die im Ordner .github/workflows/ deines Repositories liegt. Sobald du etwas pushst oder einen Pull Request öffnest, startet GitHub die Pipeline auf einem frischen virtuellen Rechner – einem sogenannten Runner.

Die wichtigsten Begriffe

Bevor wir loslegen, drei Begriffe, die du immer wieder hörst:

• Workflow: die gesamte Pipeline, beschrieben in einer YAML-Datei.
• Job: eine Gruppe von Schritten, die auf einem Runner läuft.
• Step: ein einzelner Schritt – entweder ein Befehl oder eine fertige Action.

Mehrere Jobs laufen standardmäßig parallel, die Steps innerhalb eines Jobs nacheinander.

Deine erste Workflow-Datei

Lege im Repository die Datei .github/workflows/ci.yml an. Hier eine einfache Pipeline für ein Node.js-Projekt:

name: CI

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Code auschecken
        uses: actions/checkout@v4

      - name: Node.js einrichten
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Abhängigkeiten installieren
        run: npm ci

      - name: Tests ausführen
        run: npm test

Schon nach dem Pushen dieser Datei läuft die Pipeline automatisch. Unter dem Reiter "Actions" in deinem Repository siehst du den Fortschritt.

Den Aufbau verstehen

Gehen wir die Datei durch. Der Schlüssel on legt fest, wann der Workflow läuft – hier bei jedem Push auf main und bei jedem Pull Request. Unter jobs definierst du die Arbeit. runs-on: ubuntu-latest wählt das Betriebssystem des Runners.

Spannend sind die Steps: Mit uses bindest du fertige Actions ein, etwa actions/checkout zum Holen des Codes. Mit run führst du eigene Shell-Befehle aus. So kombinierst du vorgefertigte Bausteine mit deinen eigenen Befehlen.

Mehrere Versionen mit einer Matrix testen

Oft willst du deinen Code gegen mehrere Versionen testen. Dafür gibt es die Matrix-Strategie. Der folgende Job läuft automatisch dreimal – einmal pro Node-Version:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: ['18', '20', '22']
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

So stellst du sicher, dass dein Code nicht nur auf deiner Lieblingsversion funktioniert, sondern überall.

Geheimnisse mit Secrets schützen

Brauchst du in der Pipeline ein Passwort oder einen API-Schlüssel, gehört der niemals in die YAML-Datei. Stattdessen legst du ihn in den Repository-Einstellungen unter "Secrets" an und greifst so darauf zu:

      - name: Deployment
        env:
          API_TOKEN: ${{ secrets.API_TOKEN }}
        run: ./deploy.sh

Der Wert von API_TOKEN wird in den Logs automatisch maskiert. So bleibt dein Geheimnis sicher, auch wenn andere die Logs sehen.

Fazit

Mit GitHub Actions baust du in wenigen Minuten eine funktionierende CI-Pipeline – ganz ohne externe Dienste. Du kennst jetzt die Begriffe Workflow, Job und Step, hast eine erste ci.yml erstellt und weißt, wie du mit einer Matrix gegen mehrere Versionen testest und Geheimnisse über Secrets schützt. Probiere als Nächstes aus, die Pipeline in einem eigenen Projekt einzurichten und beobachte, wie GitHub bei jedem Push automatisch deine Tests laufen lässt.