GitLab CI: .gitlab-ci.yml online formatieren und validieren

Stages, Includes, `rules:`: Struktur einer .gitlab-ci.yml prüfen, bevor die Pipeline läuft — kein GitLab-Runner, kein offizielles CI Lint.

29.08.2026

8 Min. Lektüre

Teilen Sie diesen Artikel:

GitLab CIYAMLCI/CDDevOps

Eine .gitlab-ci.yml prüfen, bevor die Pipeline startet

Eine .gitlab-ci.yml, die sich nicht einlesen lässt, ein stages, das kein Array ist, oder ein Job ohne script und ohne trigger fällt oft zu spät auf. Dann sehen Sie einen roten Badge im Pipeline Editor und einen blockierten Merge. FastMinify liefert kein offizielles GitLab CI Lint und startet keinen Runner. Der GitLab-CI-Validator führt strukturelle Prüfungen im Browser aus (Root-Mapping, stages, Jobs mit script oder trigger, include, versteckte Jobs mit .). Der GitLab-CI-Formatter rückt YAML auf 2 oder 4 Leerzeichen ein. Die ganze Werkzeugfamilie liegt im CI/CD-Hub. Zum Minifizieren von JS und CSS in derselben Pipeline siehe den CI/CD-Minifizierungsleitfaden.

Ungültiges YAML, ein falsch typisiertes stages oder einen Job ohne script und trigger vor dem Push finden

Mit 2 oder 4 Leerzeichen Einzug formatieren, für eine lesbare Prüfung

100 % im Browser: Die Datei wird nicht hochgeladen

Grenze von 512 KiB UTF-8, wie bei den anderen DevOps-Werkzeugen der Website

GitLab CI Lint (Remote-Includes, rules, offizielles Schema) bleibt bei glab und der Oberfläche

GitLab und GitHub Actions, zwei YAML-Formen in drei Schichten

Eine Root-Datei, kein Workflows-Ordner

GitHub Actions liegt unter .github/workflows/*.yml (viele Dateien, Trigger on, Jobs mit steps). GitLab CI liegt fast immer in einer einzigen .gitlab-ci.yml im Wurzelverzeichnis des Repositorys: stages, benannte Jobs, include. Die FastMinify-Werkzeuge folgen dieser Grenze, fügen Sie also keinen Actions-Workflow in den GitLab-Validator ein.

GitLab: ein YAML-Dokument, Jobs auf der obersten Ebene (außer den reservierten Keys)

GitHub: verschachtelte jobs-Map plus verpflichtendes on, siehe den GitHub-Actions-Leitfaden

Dockerfile und Compose bleiben im DevOps-Hub

Für generisches YAML (kein CI) nutzen Sie beautify-yaml

Ein minifiziertes JS-Artefakt aus einem Job ist kein CI-YAML: unminify-js

Formatieren, Validieren und CI Lint sind drei Schichten, kein einzelner Knopf

FastMinify stellt zwei Werkzeuge bereit. Keines davon ist GitLab CI Lint. Wer die drei vermischt, bekommt hier „gültig“ und scheitert trotzdem im Pipeline Editor.

Formatieren: js-yaml-Hin-und-Rück-Durchlauf mit 2 oder 4 Leerzeichen Einzug (Standard 2), siehe format-gitlab-ci

Validieren: YAML-Einlesen plus Struktur (Mapping, stages, Jobs, include), siehe validate-gitlab-ci

GitLab CI Lint: offizielles Schema, include-Expansion und Auswertung von rules:, über die Oberfläche des Pipeline-Editors, die API oder glab ci lint

YAML-Kommentare gehen beim Formatieren verloren (gleiche Grenze wie beautify-yaml): Behalten Sie eine Kopie, wenn sie zählen

Ein „Struktur OK“ beweist nicht, dass ein Remote-Include existiert oder eine rules:-Klausel den Job auswählt

Was FastMinify nicht simuliert

Der Validator spricht nicht mit einem GitLab-Runner, ruft die CI-Lint-API nicht auf und löst keine Remote-Includes auf. Die Klausel rules: ist eine echte GitLab-Funktion, die der Browser nicht auswertet.

Keine Ausführung von script, kein Docker-Image, kein Runner-Cache

Keine Expansion von include: remote oder include: project, denn nur das eingefügte YAML wird gelesen

Keine Auswertung von rules:, only/except oder workflow:rules

pages-Jobs sind normale Jobs: sie brauchen script oder trigger

Schema, Includes und rules bleiben bei GitLab CI Lint und nicht bei FastMinify

Was FastMinify in der Anatomie einer .gitlab-ci.yml prüft

Die Mindestform einer GitLab-CI-Config

Die Wurzel muss ein YAML-Mapping sein, kein Skalar und keine Liste. Es gibt nur ein Dokument, und wiederholtes --- wird abgelehnt. Wenn stages vorhanden ist, muss es ein Array nichtleerer Namen sein. Jeder Key, der nicht reserviert ist und nicht mit . beginnt, ist ein Job und braucht script (nichtleerer String oder Liste) oder trigger.

Reservierte Keys (keine Jobs): stages, variables, include, workflow, default, image, services, cache, before_script, after_script, spec

Hidden-/Template-Jobs .hidden: keine script-Pflicht

Ein Job nur mit extends erhält eine Warnung, denn ein Parent muss script oder trigger liefern

Keine Jobs und kein Top-Level-include: Warnung, nicht immer ein Blocker

Das Ergebnispanel zählt Jobs, Stages und Includes, sobald das Einlesen gelungen ist

Formatieren ist ein js-yaml-Hin-und-Rück-Durchlauf, Kommentare gehen verloren

Der Formatter schreibt YAML über js-yaml neu. Er ist kein semantisches Umschreibwerkzeug: Die Reihenfolge der Keys kann sich ändern, #-Kommentare verschwinden, und der Einzug wird 2 oder 4 Leerzeichen.

Vorher

stages: [test]
unit:
 stage: test
 script: [npm test]

Nachher

stages:
  - test
unit:
  stage: test
  script:
    - npm test

Beim Einfügen, Hochladen oder Laden des Beispiels formatiert das Werkzeug automatisch, nach einer manuellen Änderung nutzen Sie die Schaltfläche Format (⌘↵)

Einzug mit 2 oder 4 Leerzeichen (Standard 2) aus dem Dump von js-yaml, nicht von Prettier

Kommentare werden nicht erhalten: Kopieren Sie sie vorher, wenn die Datei davon abhängt

Verketten Sie format → validate für eine lesbare Prüfung und eine solide Struktur

YAML außerhalb von GitLab CI: beautify-yaml

include, rules und das 512-KiB-Limit

Ein include auf oberster Ebene reicht, um die Warnung „keine Jobs“ zu vermeiden. FastMinify lädt eingebundene Dateien nicht herunter. Über 512 KiB UTF-8 wird die Eingabe abgelehnt, wie bei den anderen DevOps-Werkzeugen der Website.

include-Zähler: ein Skalar zählt 1; ein Array zählt seine Länge

Remote-Includes bleiben undurchsichtig: GitLab CI Lint führt sie zusammen, der Browser nicht

rules: im eingefügten YAML werden nicht interpretiert

Eine leere Eingabe bleibt inaktiv und gilt nicht als „ungültig“

Eine zu große Datei: lokal glab ci lint nutzen

Erst validieren, dann formatieren, als konkreter Ablauf

Den GitLab-CI-Validator nutzen

Öffnen Sie den GitLab-CI-Validator, fügen Sie eine einzelne .gitlab-ci.yml ein (höchstens 512 KiB) und warten Sie die kurze Debounce-Pause (~300 ms) ab. Das Panel zeigt ein Ergebnis, Probleme (Einlesefehler mit Zeilenhinweis) und Zähler für Jobs, Stages und Includes.

Prüfungen: Root-Mapping, stages als Array, Jobs mit script oder trigger, include, versteckte Jobs mit .

Kein Runner, kein offizielles CI-Lint-Schema, keine entfernte Expansion von include/rules

Ein Job nur mit extends ergibt eine Warnung, ein Job ohne script und trigger einen Fehler

Alles bleibt lokal, ohne Konto und ohne Upload auf einen FastMinify-Server

YAML vor dem Merge-Request formatieren

Der GitLab-CI-Formatter schreibt YAML über js-yaml neu. Beim Einfügen, Hochladen oder Laden des Beispiels formatiert er automatisch. Nach einer manuellen Änderung nutzen Sie die Schaltfläche Format. Dieser Schritt beweist nicht, dass die Struktur vollständig ist.

Glätten Sie eine Job-Vorlage oder einen schlecht eingerückten Ausschnitt aus der Dokumentation

#-Kommentare verschwinden beim Hin- und Rückdurchlauf: Kopieren Sie sie vorher, wenn nötig

Verketten Sie format → validate für eine lesbare Prüfung und eine solide Struktur

Für YAML außerhalb von GitLab CI nutzen Sie beautify-yaml statt dieses Werkzeugs

Ein Job ohne script und ohne trigger

Ein Kollege hat compile: nur mit stage: build ergänzt. GitLab lehnt die Pipeline ab, oft mit einer Meldung, die in der Ansicht des Merge-Requests schwer lesbar ist.

Datei in validate-gitlab-ci einfügen

Öffnen Sie validate-gitlab-ci. Ein ungültiges Ergebnis wie „Job … needs script or trigger“ zeigt auf den leeren Job.

script oder trigger ergänzen

Fügen Sie script: [npm run build] oder einen echten trigger: hinzu. Fügen Sie erneut ein, bis das Panel eine gültige Struktur zeigt (Warnungen zu extends dürfen bleiben).

Formatieren und MR öffnen

Schicken Sie das korrigierte YAML durch format-gitlab-ci, kopieren Sie es und checken Sie es ein. Die Prüfenden lesen eingerückte Jobs, keinen Einzeiler.

YAML aus einem Ticket mit kaputter Einrückung

Ein Beispiel aus der GitLab-Dokumentation oder ein Ausschnitt kommt mit gemischten Leerzeichen. Sie sehen nicht mehr, wo ein Job endet.

Zuerst formatieren, wenn die Datei unlesbar ist

In format-gitlab-ci einfügen. Dieser Schritt beweist nicht, dass die Config strukturell vollständig ist.

Das eingerückte Dokument validieren

Kopieren Sie die Ausgabe in den Validator. Prüfen Sie stages und jeden Job, und achten Sie darauf, dass .-Vorlagen keinen kaputten sichtbaren Job verdecken.

CI Lint für Includes und rules behalten

Sobald die Form stimmt, bleiben Schema, Remote-Includes und rules: bei GitLab, denn FastMinify ersetzt diese Kontrolle nicht.

GitLab CI Lint (und Minify) in der Kette behalten

glab ci lint, das Schema-Sicherheitsnetz vor dem Push

Der Browser ist die schnelle Schleife für YAML und Struktur. GitLab lehnt es bereits ab, eine Pipeline zu erstellen, wenn das offizielle Schema ungültig ist, deshalb steckt selten ein „Lint-CI“-Job in derselben Datei. Lokal ruft glab ci lint (die offizielle CLI, am Projekt angemeldet) CI Lint mit zusammengeführten Includes und einer optionalen Simulation über --dry-run auf. Legen Sie Ihre glab-Version fest, denn FastMinify ersetzt diesen Aufruf nicht. Zum Minifizieren von JS und CSS in der Pipeline siehe den CI/CD-Minifizierungsleitfaden.

Einfaches Beispiel

# Local, before git push — official GitLab CI Lint (not FastMinify).
# Requires glab authenticated to the project.
glab ci lint .gitlab-ci.yml

# Optional: simulate pipeline creation (expands includes, uses --ref).
# glab ci lint --dry-run --ref main

GitHub Actions, DevOps, Unminify

Liegt das Repository auf GitHub, sind format-github-actions und validate-github-actions die Gegenstücke, mit derselben Idee aus YAML plus Struktur und ohne actionlint. Dockerfile und Compose bleiben im DevOps-Hub. Ein minifiziertes JS-Bundle aus einem Job liest man mit unminify-js oder dem Unminify-Leitfaden, und das ist kein CI-YAML.

Zusammenfassung

Fügen Sie die .gitlab-ci.yml ein, korrigieren Sie die Struktur (Mapping, stages, Jobs mit script/trigger), korrigieren Sie den Einzug und pushen Sie dann. FastMinify läuft lokal und lädt das YAML nicht hoch. Das ist kein GitLab CI Lint: Remote-Includes, rules: und das offizielle Schema bleiben in der Oberfläche, der API oder glab ci lint. Für generisches YAML bleiben Sie bei beautify-yaml. Für GitHub Actions bleiben Sie im selben CI/CD-Hub.

Jetzt eine .gitlab-ci.yml validieren oder formatieren

GitLab CI validieren GitLab CI formatieren GitHub Actions validieren CI/CD-Tools-Hub

Prüfen Sie die Struktur vor jeder MR, die .gitlab-ci.yml berührt

Formatieren Sie für die Prüfung, rechnen Sie aber damit, dass YAML-Kommentare verloren gehen