29 Appendix: Workflow Events Referenz

Die folgende Referenz dokumentiert alle verfügbaren Events, die GitHub Actions Workflows auslösen können. Die Tabellen sind nach Kategorien gegliedert und enthalten neben den Activity Types auch die wichtigsten Filter-Optionen sowie das Verhalten von GITHUB_SHA und GITHUB_REF.

29.1 Repository Events (Code & Branches)

Diese Events reagieren auf Änderungen am Repository-Inhalt, an Branches und Tags.

Das gollum-Event verdankt seinen Namen der gleichnamigen Ruby-Bibliothek, auf der GitHub Wikis basieren. Es feuert bei jeder Änderung an Wiki-Seiten – ein nützlicher Hook für Dokumentations-Workflows, der in der Praxis aber selten genutzt wird.

Das public-Event tritt ein, wenn ein privates Repository öffentlich geschaltet wird. Der umgekehrte Fall (public → private) löst kein Event aus.

29.2 Pull Request Events

Pull Requests bilden einen eigenen Event-Komplex mit mehreren spezialisierten Events für verschiedene Aspekte des PR-Lifecycles.

Der Unterschied zwischen pull_request und pull_request_target ist sicherheitskritisch:

Default Activity Types:

Sowohl pull_request als auch pull_request_target triggern standardmäßig nur bei opened, synchronize und reopened. Für andere Activity Types ist explizite Angabe via types erforderlich.

29.3 Issue & Discussion Events

Events für Issues und Discussions folgen einem ähnlichen Muster mit Activity Types für den gesamten Lifecycle.

Das issue_comment-Event feuert sowohl für Issue- als auch für PR-Kommentare. Die Unterscheidung erfolgt zur Laufzeit:

on:
  issue_comment:
    types: [created]

jobs:
  pr-comment:
    if: github.event.issue.pull_request
    runs-on: ubuntu-latest
    steps:
      - run: echo "Kommentar auf PR"
  
  issue-comment:
    if: ${{ !github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: echo "Kommentar auf Issue"

29.4 Project & Label Events

Diese Events betreffen die Projekt-Management-Funktionen von GitHub.

Diese Events beziehen sich auf die Classic Projects. Die neueren GitHub Projects (Projects v2) haben einen anderen Event-Mechanismus, der über GraphQL-Webhooks funktioniert und nicht direkt in Actions Workflows als Trigger verfügbar ist.

29.5 Release & Package Events

Bei Releases ist die Unterscheidung der Activity Types wichtig:

Draft-Releases triggern created, edited und deleted nicht. Für Draft-basierte Workflows empfiehlt sich die Kombination aus published und Logik im Workflow.

29.6 CI/CD Status Events

Diese Events ermöglichen die Reaktion auf CI/CD-Statusinformationen.

Check Runs und Check Suites haben eine Rekursions-Sperre: Events werden nicht ausgelöst, wenn die Check Suite von GitHub Actions selbst erstellt wurde oder wenn der HEAD SHA mit GitHub Actions assoziiert ist.

Das status-Event reagiert auf Commit-Status-Änderungen (die älteren Status-Checks, nicht die neueren Check Runs):

on:
  status

jobs:
  on-failure:
    if: github.event.state == 'failure'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Commit-Status ist failure"

29.7 Scheduled Events

Die Cron-Syntax folgt dem POSIX-Standard mit fünf Feldern:

┌───────────── Minute (0-59)
│ ┌───────────── Stunde (0-23)
│ │ ┌───────────── Tag des Monats (1-31)
│ │ │ ┌───────────── Monat (1-12 oder JAN-DEC)
│ │ │ │ ┌───────────── Wochentag (0-6 oder SUN-SAT)
│ │ │ │ │
* * * * *

Wichtige Einschränkungen:

• Minimales Intervall: 5 Minuten
• Läuft nur auf Default-Branch
• Bei Inaktivität (60 Tage) wird der Schedule deaktiviert
• Alle Zeiten in UTC
• Non-Standard-Syntax (@daily, @weekly) wird nicht unterstützt

29.8 Manual & External Trigger Events

workflow_dispatch Input-Typen:

on:
  workflow_dispatch:
    inputs:
      target:
        description: 'Deployment-Ziel'
        required: true
        type: choice
        options:
          - staging
          - production
      dry_run:
        description: 'Nur simulieren'
        type: boolean
        default: true

repository_dispatch ermöglicht externe Trigger via API:

curl -X POST \
  -H "Authorization: token $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/repos/OWNER/REPO/dispatches \
  -d '{"event_type":"deploy","client_payload":{"env":"prod"}}'

29.9 Workflow Orchestration Events

workflow_run ermöglicht die Verkettung von Workflows, allerdings mit Limit:

Maximal 3 Ebenen Verkettung sind möglich. Ab der 4. Ebene werden Workflows nicht mehr getriggert.

workflow_run mit Conditional:

on:
  workflow_run:
    workflows: [CI]
    types: [completed]

jobs:
  deploy:
    if: github.event.workflow_run.conclusion == 'success'
    runs-on: ubuntu-latest
    steps:
      - run: echo "CI war erfolgreich, starte Deploy"

29.10 Sonstige Events

Das watch-Event reagiert auf Stars (nicht zu verwechseln mit dem GitHub-Feature “Watch” für Notifications). Der einzig unterstützte Activity Type started entspricht dem Setzen eines Stars.

Das image_version-Event ist spezialisiert auf Container-Images und unterstützt Glob-Patterns:

on:
  image_version:
    names:
      - "my-app"
      - "my-service"
    versions:
      - "1.*"
      - "2.*"

29.11 Activity Types Übersicht

Die folgende Tabelle zeigt alle Activity Types gruppiert nach semantischer Bedeutung:

29.12 Event-Kontext-Verhalten

Nicht alle Events stellen die gleichen Informationen im github.event-Kontext bereit:

29.13 Wichtige Einschränkungen

29.14 Fork-Verhalten

PRs von Forks haben ein eingeschränktes Sicherheitsmodell: