Zum Inhalt springen

GitLab CI Validator · CI/CD

gitlab-ci.yml online validieren, bevor der Runner anläuft.

Mit diesem GitLab CI Linter validierst du deine .gitlab-ci.yml online und bekommst sowohl die YAML-Fehler als auch die strukturellen Fehlkonfigurationen, die GitLab ablehnen würde — nicht deklarierte Stages, Jobs ohne Script, defekte needs/extends. Sofort, direkt im Browser. Ohne Installation, ohne Projekt, ohne Login.

Läuft in Ihrem Browser — nichts, was Sie einfügen, verlässt diese Seite. Wie wir das belegen

Läuft in Ihrem Browser Keine Anmeldung Strukturorientiert Aktualisiert am 29.07.2026

GitLab CI Validator Playground

.gitlab-ci.yml

Runs entirely in your browser — nothing is uploaded.

Tip: press Esc to release keyboard focus from the editor.

Results

Load an example or paste a pipeline, then validate to see YAML errors and pipeline checks here.

Die Lücke

Gültiges YAML ist nur die halbe Miete.

Ein .gitlab-ci.yml kann als vollkommen gültiges YAML geparst werden und trotzdem eine defekte Pipeline sein. Die Fehler, die einen Lauf tatsächlich scheitern lassen, sind strukturell: ein Job, der auf ein stage zeigt, das Sie nie deklariert haben, ein Job ohne script, ein needs-Eintrag, der einen Job benennt, der nicht existiert, oder ein extends auf ein Template, das Sie umbenannt haben.

GitLabs eigener Pipeline-Editor und CI Lint fangen diese ab — aber erst, nachdem Sie in ein Projekt gepusht und sich angemeldet haben. Dieser Validator führt dieselben signalstarken strukturellen Prüfungen aus, bevor Sie committen, vollständig in Ihrem Browser, anhand von GitLabs .gitlab-ci.yml-Schlüsselwortreferenz.

Es prüft beides — das YAML und die Pipeline-Struktur — sodass Sie Ihre .gitlab-ci.yml online validieren und Ihre GitLab Pipeline vor dem Push prüfen können, ohne etwas zu installieren und ohne dass etwas hochgeladen wird.

Sehen Sie die vollständige Liste in den Pipeline-Prüfungen, oder probieren Sie das Live-Playground oben aus.

Die Pipeline

So funktioniert es.

Fünf deterministische Schritte laufen bei jeder Validierung von Anfang bis Ende durch — jedes Mal komplett in Ihrem Browser-Tab.

  1. Das YAML parsen.

    Ihr .gitlab-ci.yml wird mit einem YAML-Reader geparst — Syntaxfehler, falsche Einrückung und strukturelle Probleme werden mit der Zeile gemeldet, die den Fehler verursacht hat.

  2. Die Konfiguration aufteilen.

    Die oberste Ebene wird in globale Schlüsselwörter (stages, default, variables…), sichtbare Jobs und versteckte .templates aufgeteilt, sodass der Analyzer weiß, was ein Job und was Konfiguration ist.

  3. Die Stages auflösen.

    Die deklarierte stages-Liste (oder die fünf Standardwerte: .pre, build, test, deploy, .post) wird zum Set, gegen das jedes Job-Stage geprüft wird.

  4. Jeden Job prüfen.

    Jeder Job wird auf eine ausführbare Oberfläche, ein bekanntes Stage, reale needs- / extends- / dependencies-Ziele, ein gültiges when, ein als Liste geformtes rules und sinnvolle image- / services-Formen geprüft.

  5. Nach Schweregrad sortieren.

    Befunde werden als Fehler, Warnung oder Info eingestuft — die pipeline-brechenden Fehler rücken nach oben, noch vor beratende Hinweise wie das veraltete only/except, jeweils mit einer konkreten Behebung.

Pipeline-Prüfungen

Die 4 Prüfungen, auf die es ankommt.

Über die YAML-Gültigkeit hinaus sucht der Analyzer nach den Fehlkonfigurationen, die eine Pipeline scheitern lassen, bevor auch nur ein einziger Job läuft. Jede der folgenden zeigt das defekte Muster und die Lösung.

Stage nicht in stages: deklariert

Schweregrad hoch

Ein Job, dessen stage: nicht in Ihrer stages-Liste (oder einem der Standardwerte .pre, build, test, deploy, .post) steht, ist ein Konfigurationsfehler — GitLab weiß nicht, wann es ihn ausführen soll, und verweigert die Pipeline.

Defekt

.gitlab-ci.yml 
# BROKEN — "release" is not a declared stage
stages:
  - build
  - test

release-job:
  stage: release       # not in stages:
  script:
    - make release

Behoben

.gitlab-ci.yml 
# FIXED — every stage used is declared
stages:
  - build
  - test
  - release

release-job:
  stage: release
  script:
    - make release

Job ohne script / trigger / extends

Schweregrad hoch

Ein sichtbarer Job muss etwas tun: Befehle ausführen (script:/run:), eine nachgelagerte Pipeline starten (trigger:) oder all das von einem anderen Job erben (extends:). Ein Job ohne all dies wird von GitLab abgelehnt.

Defekt

job 
# BROKEN — this job does nothing
build-job:
  stage: build
  # no script, run, trigger, or extends

Behoben

job 
# FIXED — give the job a script
build-job:
  stage: build
  script:
    - make build

needs / extends zeigt auf einen fehlenden Job

Schweregrad mittel

Jeder Eintrag in needs:, dependencies: oder extends: muss auf einen Job oder ein verstecktes .template verweisen, das tatsächlich in der Datei existiert. Eine Referenz auf einen fehlenden Job zerstört den Pipeline-Graphen.

Defekt

.gitlab-ci.yml 
# BROKEN — "compile" and ".base" never exist
test:
  stage: test
  needs:
    - compile          # no such job
  extends: .base       # no such template
  script:
    - make test

Behoben

.gitlab-ci.yml 
# FIXED — references resolve to real definitions
.base:
  image: golang:1.22

compile:
  stage: build
  extends: .base
  script: make

test:
  stage: test
  needs:
    - compile
  extends: .base
  script: make test

Ungültiges when: / nicht als Liste geschriebenes rules:

Schweregrad mittel

when: akzeptiert nur on_success, on_failure, always, manual, delayed oder never. rules: muss eine YAML-Liste von Regel-Objekten sein — ein Mapping oder ein Tippfehler hier ändert (oder zerstört), wann ein Job läuft.

Defekt

job 
# BROKEN — bad when value, rules is a mapping
deploy:
  stage: deploy
  when: sometimes      # not allowed
  rules:
    if: '$CI_COMMIT_TAG'   # rules must be a list
  script: ./deploy.sh

Behoben

job 
# FIXED — valid when, rules as a list
deploy:
  stage: deploy
  rules:
    - if: '$CI_COMMIT_TAG'
      when: manual
  script: ./deploy.sh

Stages, Rules und Job-Abhängigkeiten sind alle in GitLabs Stages-Referenz und Rules-Referenz dokumentiert. Prüfungen für das veraltete only/except und die image/services-Formen laufen ebenfalls bereits heute.

Nächster Schritt

Nutzen Sie auch GitHub Actions? Validieren Sie diese Workflows.

Viele Teams betreiben Pipelines auf beiden Plattformen. Sobald Ihr .gitlab-ci.yml sauber ist, findet der GitHub Actions Validator die YAML-Fehler und Sicherheitslücken in Ihren Workflows, und der GitHub Actions Expression Tester wertet ${{ … }}-Ausdrücke aus, bevor Sie pushen — beides vollständig in Ihrem Browser.

Den Actions Validator öffnen Den Expression Tester öffnen
.gitlab-ci.yml 
stages: [build, test]

build:
  stage: build
  script: make

test:
  stage: test
  needs: [build]   # ✓ resolves
  script: make test

FAQ

Fragen, beantwortet.

Tippen Sie auf eine Frage, um die Antwort aufzuklappen.

Wie validiere ich eine .gitlab-ci.yml-Datei?

Füge dein Pipeline-YAML oben in den Playground ein — der GitLab CI Linter validiert deine .gitlab-ci.yml online und zeigt dir die Befunde sofort an. Er macht zwei Dinge gleichzeitig: Erstens parst er die Datei und meldet YAML-Syntaxfehler, falsche Einrückung und strukturelle Fehler mit der Zeile, die den Fehler verursacht hat. Zweitens führt er Prüfungen auf Pipeline-Fehlkonfigurationen durch, die genau dem entsprechen, wie GitLab selbst eine Konfiguration validiert. So kannst du deine GitLab CI YAML prüfen, ohne etwas zu installieren oder hochzuladen.

Kann ich GitLab CI ohne Projekt linten?

Ja. Dieser GitLab CI Linter läuft zu 100 % clientseitig in deinem Browser — du brauchst weder ein GitLab-Projekt noch einen Runner noch einen Login. Deine .gitlab-ci.yml wird ausschließlich im Browser-Tab geparst und analysiert; nichts wird auf einen Server hochgeladen. Du kannst bedenkenlos interne oder proprietäre Pipelines einfügen, auch solche mit privaten Runner-Tags, internen Image-Namen und Referenzen auf geheime Variablen.

Warum meldet GitLab „this GitLab CI configuration is invalid“?

Diese Meldung bedeutet, dass deine .gitlab-ci.yml zwar als YAML lesbar sein kann, aber gegen GitLabs Pipeline-Regeln verstößt. Typische Ursachen: ein Job ohne script / run / trigger / extends, ein stage, das nicht in deiner stages-Liste steht, needs- oder extends-Referenzen auf nicht existierende Jobs, ein ungültiger when-Wert oder ein rules-Block, der keine Liste ist. Wenn du deine GitLab CI Konfiguration hier prüfst, zeigt der Validator dir genau, welche dieser strukturellen Fehler die Pipeline ungültig machen — mit einer konkreten Behebung je Befund.

Wie prüfe ich meine .gitlab-ci.yml auf Fehler, bevor ich pushe?

Füge das Pipeline-YAML in diesen browserbasierten Validator ein, um Fehler vor dem Commit abzufangen — ohne Installation und ohne Push. Das Tool führt den vollständigen Prüfsatz (YAML-Struktur plus Pipeline-Fehlkonfigurationen) vollständig im Browser aus, sodass du sofortiges Feedback zu Syntaxfehlern, nicht deklarierten Stages, Jobs ohne Scripts, defekten needs/extends und ungültigen when-Werten erhältst, bevor die Konfiguration jemals einen GitLab-Runner erreicht. So lässt sich eine GitLab Pipeline validieren, während du noch bearbeitest.

Gibt es einen kostenlosen Online-GitLab-CI-Validator ohne Login?

Ja — genau das ist dieses Tool. Du kannst deine .gitlab-ci.yml validieren, ohne dich anzumelden, ein Konto anzulegen oder etwas zu installieren. Es ist kostenlos, läuft vollständig im Browser und lädt nichts hoch. Im Gegensatz zum integrierten CI Lint von GitLab, das ein Projekt, eine Anmeldung und einen Roundtrip zum Server voraussetzt, gibt dir dieser Linter sofortiges, offline verfügbares Feedback zu den signalstarken strukturellen Fehlern. Behandle ein sauberes Ergebnis hier als starke Sicherheit vor dem Push und bestätige es anschließend mit GitLabs CI Lint.

Was prüft der GitLab CI Lint genau?

Der Validator prüft zwei Ebenen. Auf YAML-Ebene meldet er Syntaxfehler, falsche Einrückung und strukturelle Probleme mit der betroffenen Zeile. Auf Pipeline-Ebene erkennt er: einen Job ohne script / run / trigger / extends, ein stage, das nicht in deiner stages-Liste steht, needs- und extends-Referenzen auf nicht existierende Jobs, einen ungültigen when-Wert, einen rules-Block, der keine Liste ist, das veraltete only/except sowie fehlerhafte image/services-Formen. GitLab stellt übrigens fünf implizite Standard-Stages bereit (.pre, build, test, deploy, .post), gegen die jedes Job-Stage geprüft wird.

Wie behebe ich den Fehler „did not find expected key“ in GitLab CI?

Dieser YAML-Fehler entsteht fast immer durch falsche Einrückung oder eine fehlende Doppelpunkt-Struktur in deiner .gitlab-ci.yml — etwa ein Schlüssel, der unter dem falschen Mapping eingerückt ist, gemischte Tabs und Leerzeichen oder eine Liste, die als Mapping geschrieben wurde. Füge die Konfiguration in diesen GitLab CI Linter ein: Er meldet den Parse-Fehler mit der genauen Zeile, sodass du die Einrückung an der richtigen Stelle korrigierst, statt zu raten.

Warum scheitert mein GitLab-CI-Job mit „job has no script“?

Ein sichtbarer GitLab-Job muss etwas tun: Befehle ausführen (script: / run:), eine nachgelagerte Pipeline starten (trigger:) oder all das über extends: von einem anderen Job oder versteckten Template erben. Ein Job, der keines davon definiert, wird mit einer Meldung wie „job config should implement a script: or a trigger: keyword“ abgelehnt. Der Validator markiert jeden sichtbaren Job, dem alle vier fehlen. Versteckte Templates (Schlüssel, die mit einem Punkt beginnen) dürfen partielle Fragmente sein und benötigen daher kein script.

More free, private DevOps tools.

Der GitLab CI Validator ist eines von vielen Tools in OpsCanopy — einem wachsenden Schirm browserbasierter Validatoren, Konverter und Tester, die niemals einen Server berühren.

Mehr aus CI/CD

Mehr dazu lesen

Neu bei Docker?  Zum Docker-Guide →

Browse All Tools Back to OpsCanopy

39 kostenlose Tools, jedes einzelne offlinefähig — opscanopy.com funktioniert ohne Registrierung, und nichts wird hochgeladen.

Verwandte Tools: der GitHub Actions Validator und der GitHub Actions Expression Tester. Durchsuchen Sie das vollständige Tools-Verzeichnis.

Nicht verbunden mit, unterstützt von oder gesponsert durch GitLab B.V. GitLab ist eine Marke von GitLab B.V., hier ausschließlich beschreibend verwendet, um das .gitlab-ci.yml-Pipeline- Format zu kennzeichnen, das dieses Tool prüft.