GitHub Actions: Workflow-YAML prüfen und korrigieren

Warum ein Workflow prüfen, bevor er auf main landet?

Eine Datei .github/workflows/*.yml, die nicht parst, oder ein Job ohne runs-on, fällt oft erst nach dem Push auf: roter Haken, GitHub-Logs, blockierte Review. FastMinify liefert kein actionlint. Der GitHub-Actions-Validator prüft strukturell im Browser — on, jobs, steps mit run oder uses — und der GitHub-Actions-Formatter rückt YAML ein (2-Leerzeichen-Konvention). Der Cluster liegt im CI/CD-Hub. JS/CSS in der Pipeline minifizieren: CI/CD-Minifizierungsleitfaden.

Ungültiges YAML, fehlendes on/jobs oder einen leeren Step vor dem Push finden

2-Leerzeichen-Einzug für lesbare Reviews formatieren

100 % im Browser — der Workflow wird nicht hochgeladen

512 KiB UTF-8-Limit, wie bei den anderen DevOps-Tools

actionlint (${{ }}-Ausdrücke) und Action-Pins bleiben in der CI

Workflow-Anatomie: was FastMinify prüft (und was nicht)

Die Mindestform eines GitHub-Actions-Workflows

Ein Workflow ist ein einziges YAML-Dokument. GitHub erwartet einen Trigger on und eine Map jobs. Jeder Job braucht einen Runner (runs-on), einen wiederverwendbaren Workflow (uses) oder eine steps-Liste. Jeder Step muss run oder uses definieren.

Ein YAML-Dokument — Mehrfachdokumente (wiederholtes ---) werden abgelehnt

Die Wurzel muss ein Mapping sein, kein Skalar und keine Liste

Wiederverwendbare Jobs: uses auf Job-Ebene ohne steps ist zulässig; verschachteltes YAML wird nicht tief geprüft

Leeres jobs oder leere steps ergeben eine Warnung, nicht immer einen Blocker

Das Ergebnispanel zählt Jobs, Steps und on-Trigger nach erfolgreichem Parse

Formatieren, validieren, actionlint: drei Schichten, kein Knopf

FastMinify stellt zwei Tools bereit. Keines davon ist actionlint. Wer die drei vermischt, bekommt Workflows, die „gültig“ aussehen und in der CI trotzdem scheitern.

Before

name: CI
on: push
jobs:
 build:
  runs-on: ubuntu-latest
  steps:
  - uses: actions/checkout@v4
  - run: npm test

After

name: CI
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

Formatieren: js-yaml-Roundtrip, 2-Leerzeichen-Einzug (GitHub-Konvention) — siehe format-github-actions

Validieren: YAML-Parse plus Form von on / jobs / Steps — siehe validate-github-actions

actionlint: ${{ }}-Ausdrücke, Permissions, IDs, Action-Lookup — in der CI, nicht in FastMinify

YAML-Kommentare gehen beim Formatieren verloren (gleiche Grenze wie beautify-yaml) — Kopie behalten, wenn Sie darauf angewiesen sind

Ein „Struktur OK“ beweist nicht, dass actions/checkout@v4 existiert oder ein Ausdruck sicher ist

${{ }}-Ausdrücke und Injection: außerhalb des Browser-Scopes

Nicht vertrauenswürdigen Kontext (github.event.issue.title, ein PR-Label) direkt in run: zu interpolieren ist ein klassisches Script-Injection-Muster. FastMinify wertet keine Ausdrücke aus und markiert dieses Muster nicht.

Nicht vertrauenswürdige Werte über env: übergeben, nicht in das Skript interpolieren

permissions: auf das Minimum beschränken (contents, pull-requests)

Action-SHAs oder geprüfte Tags pinnen statt einer ungeprüften Gleitreferenz

actionlint und eine menschliche Review bleiben das Netz für dieses Risiko

Der FastMinify-Validator akzeptiert einen Step mit run oder uses — auch wenn das Skript unsicher ist

Validieren, dann formatieren: ein konkreter Ablauf

Den GitHub-Actions-Validator nutzen

Öffnen Sie den GitHub-Actions-Validator, fügen Sie eine einzelne Workflow-Datei ein (max. 512 KiB) und warten Sie auf Debounce (~300 ms). Das Panel zeigt Verdict, Issues mit Zeilenhinweis bei Parse-Fehlern und Zähler für Jobs/Steps/Trigger. Leeres Feld bleibt idle — nicht „ungültig“.

Prüfungen: on, jobs, runs-on oder uses oder steps, jeder Step mit run oder uses

Kein Marketplace-Lookup, keine ${{ }}-Auswertung, kein Action-Pinning

Wiederverwendbare Jobs (uses auf Job-Ebene) ohne steps zulässig

Alles bleibt lokal — kein Konto, kein Upload zu einem FastMinify-Server

YAML vor der Pull Request formatieren

Der GitHub-Actions-Formatter pretty-printet via js-yaml. Einfügen, Upload oder Sample: Auto-Format; nach manueller Bearbeitung den Format-Button (⌘↵). Die UI folgt der 2-Leerzeichen-Konvention. Das ist kein semantischer Rewriter.

Gist oder schlecht eingerücktes Docs-Beispiel glätten

#-Kommentare verschwinden im Roundtrip — vorher kopieren, wenn nötig

Format → Validate verketten für lesbare Review und gesunde Struktur

Für YAML außerhalb von Actions beautify-yaml nutzen, nicht dieses Tool

Szenario — Step ohne run und ohne uses

Ein Teammitglied hat - name: empty step ohne Skript ergänzt. Die CI scheitert spät, mit einer GitHub-Meldung, die im PR-Overlay schwer lesbar ist.

Schritt 1: Workflow in validate-github-actions einfügen

Öffnen Sie validate-github-actions. Ein ungültiges Verdict wie „step needs run or uses“ zeigt auf den leeren Step.

Schritt 2: run oder uses ergänzen

Den Step durch uses: actions/checkout@v4 oder ein echtes run: ersetzen. Erneut einfügen, bis das Panel eine gültige Struktur zeigt.

Schritt 3: formatieren und PR öffnen

Das korrigierte YAML durch format-github-actions schicken, kopieren, committen. Reviewer lesen eingerückte Jobs, kein Blob.

Szenario — Workflow aus einem Ticket, kaputte Einrückung

Ein Beispiel aus der GitHub-Doku oder einem Gist kommt mit gemischten Leerzeichen. Sie sehen nicht mehr, wo ein Job endet.

Schritt 1: zuerst formatieren, wenn die Datei unlesbar ist

In format-github-actions einfügen. Dieser Schritt beweist nicht, dass der Workflow strukturell vollständig ist.

Schritt 2: das eingerückte Dokument validieren

Die Ausgabe in den Validator kopieren. on, jobs und jeden Step mit Action prüfen.

Schritt 3: actionlint in der CI behalten

Ist die Form in Ordnung, bleiben Ausdrücke / IDs / Marketplace in der Pipeline — FastMinify ersetzt dieses Gate nicht.

actionlint (und Minify) in der CI behalten

Beispiel-Job actionlint — im Repository pinnen

Der Browser ist die schnelle Schleife vor git push. Teams behalten actionlint als Merge-Gate für ${{ }}-Ausdrücke und Regeln, die FastMinify nicht umsetzt. Das Snippet folgt dem offiziellen actionlint-Download-Skript: eine Version im Repo pinnen, kein gleitendes main. JS/CSS in derselben Pipeline minifizieren: CI/CD-Minifizierungsleitfaden.

Basic example

name: Lint GitHub Actions workflows
on:
  pull_request:
    paths:
      - '.github/workflows/**'
jobs:
  actionlint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check workflow files
        run: |
          bash <(curl https://raw.githubusercontent.com/rhysd/actionlint/main/scripts/download-actionlint.bash)
          ./actionlint -color
        shell: bash

GitLab CI und der Rest des Hubs

Liegt das Repo auf GitLab, sind die Pendants format-gitlab-ci und validate-gitlab-ci — dieselbe Idee (YAML plus Struktur, kein Runner). Dockerfile und Compose bleiben im DevOps-Hub: Dockerfile linten, Compose und .env validieren.

Fazit

Workflow einfügen, Struktur korrigieren (on, jobs, Steps), neu einrücken, dann pushen. FastMinify macht diese Schleife lokal und lädt das YAML nicht hoch. Das ist kein actionlint: Ausdrücke, erweiterte Permissions und die Existenz von Actions bleiben in CI und Review. Für generisches YAML bei beautify-yaml bleiben; für GitLab im selben CI/CD-Hub.

GitHub-Actions-Workflow jetzt validieren oder formatieren

Struktur vor jeder PR prüfen, die .github/workflows berührt

Für die Review formatieren, YAML-Kommentare gehen dabei verloren

Ein FastMinify-Verdict nicht als actionlint-Grünlicht behandeln

${{ }}-Injection und Action-Pins in Review plus CI behalten

Validate → Format verketten, dann actionlint beim Merge