CI/CD-Tools

GitHub Actions Workflow Validatorformatieren, prüfen und durch jeden Job springen

Workflow-YAML einfügen, formatieren lassen, den Job/Step-Baum durchgehen und Matrix- oder Cron-Entwürfe vor dem Einfügen erst prüfen.

GitHub Actions Workflow Validator

Workflow-YAML

Ergebnis

Alles läuft nur im Browser, nichts wird an GitHub oder einen Server gesendet.

Optionen
Matrix-Generator (Entwurf)

Variablen

include (optional)

exclude (optional)

Vorschau erzeugen, um das strategy.matrix-Snippet zu sehen.

Cron-Zeitplan-Generator (Entwurf)

Vorschau erzeugen, um das on.schedule-Snippet zu sehen.

Wartet auf Validierung…

Eine GitHub Actions Workflow-YAML-Datei bricht meist erst nach dem Push — ein Job ohne runs-on, ein permissions-Wert, den es gar nicht gibt, oder ein Zeitplan, der nie feuert. Dieser GitHub Actions Workflow Validator findet solche Fehler lokal, bevor überhaupt ein Run startet, weil er die Struktur prüft, auf die die CI tatsächlich angewiesen ist, statt nur generische YAML-Syntax.

Nützlich, wenn ein langer Workflow mit mehreren Jobs bearbeitet wird und die kaputte Stelle schnell gefunden werden soll, wenn eine Build-Matrix über Betriebssysteme und Versionen entsteht, wenn env-, secrets- und vars-Referenzen über mehrere Steps hinweg sortiert werden müssen, oder wenn ein on.schedule-Cron-Ausdruck geschrieben wird und klar sein soll, was GitHub Actions selbst überhaupt erlaubt.

Warum dieser GitHub Actions Workflow Validator

Eine Werkbank statt zwischen einem generischen YAML-Linter, einem Matrix-Generator und einem Cron-Tool zu wechseln, das GitHub Actions gar nicht kennt.

Formatieren, Strukturprüfung und Job/Step-Navigation an einem Ort

Ein eingefügter Workflow wird formatiert, Job-id und Step-id werden gegen die Namensregel geprüft, jeder Job wird auf runs-on oder uses kontrolliert, permissions-Werte gegen das echte Enum geprüft (id-token nur write oder none) und gleichzeitige branches/branches-ignore-Filter werden gemeldet — dazu ein klickbarer Job/Step-Baum, der den Editor direkt zur passenden Zeile springen lässt.

Regeln und Grenzen ansehen
Formatiertes GitHub Actions Workflow YAML neben einem klickbaren Job- und Step-Navigationsbaum mit hervorgehobenem Strukturfehler

Sehen, wo env-, secrets- und github-Referenzen wirklich scheitern

Das Referenz-Panel listet jeden gefundenen ${{ env.X }}-, ${{ secrets.X }}-, ${{ vars.X }}- und ${{ github.X }}-Ausdruck samt zugehörigem Job und Step und markiert die drei dokumentierten Fehlerstellen: env darf nicht in der id oder in uses eines Steps stehen, secrets darf nicht direkt in einer if:-Bedingung gelesen werden, und github darf nicht in uses: verwendet werden.

Referenzerkennung ansehen
Liste von env-, secrets-, vars- und github-Referenzen mit drei markierten Stellen, an denen GitHub Actions tatsächlich einen Fehler wirft

Ein Cron-Baukasten, der die eigenen Grenzen von GitHub Actions bereits kennt

Der Cron-Bereich baut einen fünfteiligen Standardausdruck und wendet dabei die Grenzen an, die GitHub für schedule dokumentiert: mindestens fünf Minuten Abstand, standardmäßig UTC mit optionaler IANA-Zeitzone, keine Aliase wie @daily, und die automatische Deaktivierung nach 60 Tagen Inaktivität bei öffentlichen Repositories.

FAQ zu Zeitplänen lesen
Cron-Baukasten mit Anzeige des Fünf-Minuten-Mindestabstands, UTC-Standard und Warnung vor nicht unterstützten Aliasen von GitHub Actions

Drei Dinge, die beim ersten Öffnen leicht übersehen werden

Im Hintergrund passiert mehr, als die Toolbar zeigt.

01

Workflow einfügen oder Beispiel laden

Workflow-YAML aus dem eigenen Editor einfügen oder das eingebaute Beispiel laden — es enthält bereits einen Zeitplan-Trigger, einen Job mit strategy.matrix sowie env-, secrets- und github-Referenzen, sodass alle fünf Funktionen auf einen Blick sichtbar sind. Die automatische Prüfung ist standardmäßig aktiv und läuft 350ms nach der letzten Eingabe erneut; nichts wird hochgeladen.

  • Ein Klick auf einen Job- oder Step-Namen im Navigationsbaum springt im Editor direkt zur passenden Zeile — spart vor allem bei Workflows mit mehr als ein paar Jobs echte Zeit.
02

Matrix- und Cron-Panel sind Entwürfe, keine Live-Änderung

Änderungen an der Matrix-Variablentabelle oder den Cron-Feldern wirken sich nie von selbst auf den Workflow aus, sondern erzeugen nur eine Vorschau. Erst ein Klick auf Einfügen schreibt etwas in strategy.matrix oder on.schedule; bis dahin lässt sich der Entwurf trotzdem einzeln kopieren.

  • Versionsnummern wie node-version: "3.10" in Anführungszeichen setzen — ohne Anführungszeichen liest YAML 3.10 als Zahl 3.1 und verliert die abschließende Null.
  • fail-fast ist standardmäßig true, max-parallel bleibt leer (unbegrenzt) — genau wie bei GitHub Actions selbst.
03

Risikomarkierungen lesen, bevor ein fehlerfreies Ergebnis vertraut wird

Die env/secrets/vars/github-Referenzliste markiert genau die Stellen, an denen GitHub Actions dokumentiert einen Fehler wirft — keine Vermutung eines generischen Linters. Bei ausgeschalteter automatischer Prüfung löst Strg/Cmd+Enter eine erneute Prüfung aus; wird danach weiter editiert, bleiben Kopieren und Herunterladen gesperrt, bis erneut geprüft wurde, damit nie ein veralteter Stand exportiert wird.

  • Ein Filter über der Referenzliste blendet alles außer env, secrets, vars oder github aus — hilfreich bei vielen Ausdrücken.

Was im Hintergrund tatsächlich passiert

Fünf Funktionen, die zusammenarbeiten statt fünf getrennte Tabs zu sein.

YAML-Formatierung mit wählbarer Einrückung

Ein Workflow lässt sich mit durchgehend zwei oder vier Leerzeichen neu formatieren, sodass ein Pull-Request-Diff nur die tatsächlich geänderten Zeilen zeigt statt einer komplett umformatierten Datei.

Strukturprüfungen anhand echter Workflow-Regeln

Job- und Step-ids werden gegen das erforderliche Namensmuster geprüft, jeder Job wird auf runs-on oder uses kontrolliert, permissions-Werte werden gegen ihr echtes Enum geprüft, und sich gegenseitig ausschließende Filter wie branches und branches-ignore werden gemeldet, wenn beide im selben Trigger stehen.

Klickbarer Job/Step-Navigationsbaum

Der Baum bildet die tatsächliche Job- und Step-Struktur des Workflows ab; ein Klick auf einen Eintrag scrollt den Editor exakt zu dieser Zeile, statt Einrückungsebenen mühsam abzuzählen.

Matrix-Generator mit include, exclude und fail-fast

Eine Variablentabelle nach os/Version aufbauen, include- oder exclude-Kombinationen ergänzen, fail-fast und max-parallel setzen, das entstehende strategy.matrix in der Vorschau prüfen und in den gewählten Job einfügen.

env/secrets/vars/github-Referenzübersicht

Jeder ${{ }}-Ausdruck, der env, secrets, vars oder github referenziert, wird extrahiert und nach Job und Step aufgelistet, mit Filter für genau einen dieser Kontexte.

Cron-Schnipsel-Generator eigens für GitHub Actions

Ein fünfteiliger Zeitplan aus gängigen Vorlagen oder einem eigenen Ausdruck, mit Vorschau des genauen on.schedule-Eintrags vor dem Einfügen — GitHub Actions' eigene Zeitplan-Grenzen werden automatisch angewendet, statt sie sich merken zu müssen.

Was geprüft wird, und was bewusst fehlt

Die Grenzen zu kennen zählt mehr als eine lange Funktionsliste.

Keine Verbindung zu GitHub
Dieser GitHub Actions Workflow Validator liest ausschließlich lokal. Er ruft nie die GitHub-API auf, forkt oder pusht kein Repository und löst oder startet nie einen Workflow — er formatiert und prüft nur den eingefügten Text, komplett auf dem eigenen Gerät.
Ausdrücke werden nicht ausgewertet
${{ github.sha }} oder ${{ steps.build.outputs.version }} werden extrahiert und aufgelistet, aber nicht zu einem echten Laufzeitwert aufgelöst. Das echte Verhalten von Ausdrücken zu testen braucht eine eigene Auswertungs-Engine — ein separates Tool, das hier bewusst nicht mit einem JavaScript-eval vorgetäuscht wird.
Schema-Prüfung ist eine gezielte Teilmenge, kein actionlint
Die Strukturprüfung deckt den Teil des öffentlichen schemastore.org-Schemas ab, der nicht von externen Metadaten abhängt: Job/Step-ids, runs-on/uses, permissions, Filterkonflikte. Input-Typen von Actions, Marketplace-Action-Versionen oder eine aktuelle Liste unterstützter Runner-Labels werden nicht geprüft, weil solche Metadaten offline gecacht sofort veralten.
Kein Abhängigkeitsgraph
Der Job/Step-Baum zeigt Struktur, keinen gerenderten DAG der needs:-Beziehungen zwischen Jobs. Wer einen visuellen Abhängigkeitsgraphen braucht, braucht eine andere Art von Darstellung — das versucht dieses Tool bisher nicht.
Zeitplan-Grenzen sind dokumentiert, aber nicht garantiert
Der Cron-Baukasten setzt GitHubs veröffentlichte Regeln durch — fünf Minuten Minimum, standardmäßig UTC, keine Aliase wie @daily —, kann aber nicht versprechen, dass das optionale timezone-Feld beachtet wird oder ein Zeitplan exakt zur eingestellten Minute feuert; GitHub weist selbst auf mögliche Verzögerungen bei hoher Last und die automatische Deaktivierung nach 60 Tagen Inaktivität hin.

GitHub Actions Workflow Validator – häufige Fragen

Antworten, die sich auf GitHubs eigene Dokumentation stützen, nicht auf Vermutungen.

Funktioniert das timezone-Feld in einem GitHub Actions Cron-Zeitplan wirklich?

Der erzeugte Eintrag ist syntaktisch korrekt — GitHub hat 2024 die optionale IANA-Zeitzone für schedule eingeführt. In GitHubs eigenen Community-Diskussionen gibt es aber reale Berichte, dass sie nicht angewendet wurde. Dieser Validator garantiert nur, dass der Schnipsel der veröffentlichten Syntax entspricht — nicht, dass GitHubs Scheduler sie tatsächlich beachtet.

Warum läuft mein GitHub Actions Cron-Zeitplan nicht zur eingestellten Zeit?

Ein paar reale Ursachen: Die Workflow-Datei liegt nicht auf dem Standard-Branch, das Repository war inaktiv und GitHub hat den Zeitplan nach 60 Tagen automatisch deaktiviert, oder der Ausdruck nutzt ein kürzeres Intervall als das dokumentierte Minimum von fünf Minuten. GitHub weist außerdem darauf hin, dass geplante Runs bei hoher Last verzögert werden können, besonders rund um volle Stunden — dieses Tool prüft die Cron-Syntax, kann aber die exakte Auslösezeit nicht garantieren.

GitHub zeigt nur "you have an error in your yaml syntax" — in welcher Zeile genau?

Den Workflow in diesen GitHub Actions Workflow Validator einfügen: Er nennt den genauen Job- oder Step-Namen samt Zeile und Spalte, statt GitHubs allgemeiner Meldung. Die automatische Prüfung läuft 350ms nach der letzten Eingabe erneut, sodass sich die markierte Stelle beim Bearbeiten mitbewegt.

Warum meldet with: in einem reusable Workflow "Unrecognized named-value: 'env'"?

Weil der env-Kontext innerhalb von with: gar nicht verfügbar ist — eine von drei dokumentierten Einschränkungen, die das Referenz-Panel direkt markiert (env ist auch in der id und in uses eines Steps nicht erlaubt). Den Wert stattdessen in ein job- oder workflow-weites env legen oder explizit als Input an den reusable Workflow übergeben.

Warum funktioniert ein secrets-Wert nicht, der direkt aus der Dokumentation kopiert wurde?

Meist, weil er in einer if:-Bedingung steht — secrets lässt sich dort nicht direkt lesen. Den Wert erst einer job- oder step-weiten env-Variable zuweisen und dann diesen env-Wert in der if:-Bedingung prüfen. Genau das ist eine der drei Risikostellen, die das Referenz-Panel für jede secrets.*-Referenz markiert.

Warum wird aus der Matrix-Versionsnummer 3.10 plötzlich 3.1?

YAML liest ein unquotiertes 3.10 als Zahl 3.1 und verliert stillschweigend die abschließende Null — eine Eigenheit von YAML, kein Fehler von GitHub Actions. Der Matrix-Generator erkennt versionsartige Werte und setzt beim Einfügen des erzeugten strategy.matrix automatisch Anführungszeichen.

Einen Workflow gefunden, bei dem das Tool falsch liegt?

Weitere CI/CD- und Zeitplan-Tools entdecken

Weitere Werkbänke für Workflow-YAML, Cron-Ausdrücke und Pipeline-Konfiguration.

Alle CI/CD-Tools ansehen

Diesen GitHub Actions Workflow Validator jetzt ausprobieren

Workflow in diesen GitHub Actions Workflow Validator einfügen, dabei zusehen, wie sich Job/Step-Baum und Referenzliste aktualisieren, und bei Bedarf einen Matrix- oder Cron-Entwurf erstellen.

Alles bleibt im Browser — nichts wird hochgeladen, und kein Workflow wird jemals ausgelöst.

Zurück zur Werkbank CI/CD-Tools ansehen

Die gesamte Verarbeitung läuft lokal im Browser.