Erstellen von zuverlässigen Workflows – Ausgaben, Kontexte, Trigger und Übergaben zwischen Aufgaben

In dieser Lektion lernen Sie Folgendes:

• Übergeben von Daten über Workflows mithilfe von Schritt- und Auftragsausgaben

• Verwenden von GitHub Kontexten für Konfiguration und Steuerung

• So entwerfen Sie Workflows mit sicheren Triggern und defensivem Gating

• Sicherstellen, dass Workflows nur im richtigen Kontext ausgeführt werden

• So erstellen Sie zuverlässige Workflows mithilfe strukturierter Daten und Ereignislogik

Autonomie muss entworfen werden, nicht angenommen

Unterschiedliche Aufgaben tragen unterschiedliche Risiken. Eine gute Agentarchitektur verwendet Richtlinien, um unterschiedliche Autonomiestufen auszudrücken, anstatt überall dieselben Regeln anzuwenden.

Ein einfaches risikobasiertes Autonomiemodell könnte wie folgt aussehen:

Implementierung: Umgebungsgenehmigungen für die Ausführung mit hohem Risiko

Umgebungen bieten einen starken Kontrollpunkt für riskante Aktionen wie Bereitstellungen und Zugriff auf geschützte geheime Daten. Wenn eine Umgebung mit den erforderlichen Prüfern konfiguriert ist, wird ein Auftrag für diese Umgebung angehalten, bis die Genehmigung erteilt wird.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
    steps:
      - run: echo "Deploying to production..."

Mit diesem Entwurf kann der Agent Änderungen vorbereiten und gleichzeitig verhindern, dass Aktionen, die sich auf die Produktion auswirken, unabhängig ausgeführt werden.

Ausgaben sind Workflow-Verträge (Step Outputs vs Job Outputs vs Env)

Wenn ein Workflow Informationen generiert, die nachgelagerte Schritte oder Aufträge nutzen müssen, diese Daten als explizite Ausgabe und nicht als „nur Protokolle” behandeln.

Lehren und Anwenden dieser Prinzipien:

• Schrittausgaben übergeben Werte zwischen Schritten in demselben Auftrag.

• Auftragsausgaben übergeben Werte über Aufträge hinweg (über Auftragsabhängigkeiten).

• Umgebungsvariablen konfigurieren das Laufzeitverhalten, sollten jedoch keine Ausgaben für strukturierten Datenfluss ersetzen.

Veranschaulichungsmuster (Mechanik wird dargestellt, aber nicht in Prüfungsform):

- id: generate_plan
  run: |
    echo "plan=high level steps..." >> "$GITHUB_OUTPUT"

- run: |
    echo "Plan: ${{ steps.generate_plan.outputs.plan }}"

Für die funktionsübergreifende Freigabe eine Auftragsausgabe veröffentlichen und von einem abhängigen Auftrag darauf verweisen:

jobs:
  plan:
    outputs:
      plan: ${{ steps.generate_plan.outputs.plan }}
    steps:
      - id: generate_plan
        run: echo "plan=..." >> "$GITHUB_OUTPUT"

  implement:
    needs: plan
    steps:
      - run: echo "Using plan: ${{ needs.plan.outputs.plan }}"

Kontexte: GitHub vs vars vs env

Verwenden Sie den richtigen Kontext für den richtigen Zweck:

• github.* → Ereignismetadaten und Laufzeitentscheidungen ("Was hat diese Ausführung ausgelöst?")

• vars.* → zentral verwaltete Konfigurationswerte, die wiederverwendet werden sollen

• env.* → Umgebungsvariablen auf Auftragsebene und Laufzeitkonfiguration

Sicheres Auslösen und defensives Gating

Selbst wenn Workflows für PRs entwickelt wurden, verfügen Repositorien häufig über mehrere Trigger. Defensive Gating-Mechanismen hinzufügen, sodass das „PR-only”-Verhalten nicht versehentlich ohne PR-Kontext ausgeführt wird.

Allgemeines Muster zum Lehren:

• Verwenden Sie Bedingungen auf Auftragsebene, um sicherzustellen, dass PR-abhängige Aktionen nur ausgeführt werden, wenn die Ausführung an ein PR-Ereignis gebunden ist.

Defensives Gating für das Verhalten von nur-Pull-Anfragen

Auch wenn ein Workflow nur für Pullanforderungen ausgeführt werden soll, kann er auch von anderen Ereignissen (z. B. Push, workflow_dispatch oder Zeitplan) ausgelöst werden. Ohne zusätzliche Schutzmaßnahmen können PR-spezifische Schritte, wie z. B. das Schreiben eines Kommentars zu einer Pull-Request oder das Bewerten von Änderungen, fehlschlagen oder sich unerwartet verhalten.

Sie können dies verhindern, indem Sie eine Bedingung auf Auftragsebene hinzufügen, die sicherstellt, dass der Workflow nur ausgeführt wird, wenn er einer Pullanforderung zugeordnet ist.

name: PR Validation

on:
  pull_request:
    branches: [ main ]
  workflow_dispatch: # allows manual runs, but still gated below

jobs:
  validate-pr:
    # Defensive gating: only run if this is actually a PR context
    if: github.event_name == 'pull_request'

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run tests
        run: npm test

      - name: Comment on PR
        run: echo "Validation complete"

Wichtige Erkenntnis: Die Zuverlässigkeit von Workflows verbessert sich, wenn Pläne und Signale als strukturierte Ausgaben behandelt und durch ereignisfähige Logik geschützt werden.

Als Nächstes Agenten sicher betreiben. Dazu Läufe auditierbar machen, Tools und Geheimnisse kontrollieren und auf Hooks basierende Schutzmechanismen und Zuverlässigkeitsmuster erstellen.