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

Warum ein .gitlab-ci.yml prüfen, bevor die Pipeline startet?

Ein .gitlab-ci.yml, das nicht parst, ein stages, das kein Array ist, oder ein Job ohne script und ohne trigger, fällt oft zu spät auf: roter Badge, Pipeline Editor, blockierter Merge. FastMinify liefert kein offizielles GitLab CI Lint und startet keinen Runner. Der GitLab-CI-Validator prüft strukturell im Browser — Root-Mapping, stages, Jobs mit script oder trigger, include, Hidden Jobs . — und der GitLab-CI-Formatter rückt YAML ein (2 oder 4 Leerzeichen). Der Cluster liegt im CI/CD-Hub. JS/CSS in derselben Pipeline minifizieren: CI/CD-Minifizierungsleitfaden.

Ungültiges YAML, falsch typisierte stages oder einen Job ohne script/trigger vor dem Push finden

Einzug 2 oder 4 Leerzeichen für lesbare Reviews formatieren

100 % im Browser — die Datei wird nicht hochgeladen

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

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

GitLab vs GitHub Actions: zwei YAML-Formen, drei Schichten

Eine Root-Datei, kein Workflows-Ordner

GitHub Actions lebt unter .github/workflows/*.yml (viele Dateien, Trigger on, Jobs mit steps). GitLab CI liegt fast immer in einer einzigen .gitlab-ci.yml im Repo-Root: stages, benannte Jobs, include. Die FastMinify-Tools folgen dieser Grenze — kleben Sie keinen Actions-Workflow in den GitLab-Validator.

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

GitHub: verschachtelte jobs-Map plus Pflicht-on — siehe den GitHub-Actions-Leitfaden

Dockerfile und Compose bleiben im DevOps-Hub

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

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

Formatieren, validieren, CI Lint: drei Schichten, kein Knopf

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

Formatieren: js-yaml-Roundtrip, Einzug 2 oder 4 Leerzeichen (Standard 2) — siehe format-gitlab-ci

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

GitLab CI Lint: offizielles Schema, include-Expansion, Auswertung von rules: — Pipeline-Editor-UI, API oder glab ci lint

YAML-Kommentare gehen beim Formatieren verloren (gleiche Grenze wie beautify-yaml) — Kopie behalten, wenn sie zählen

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

Was FastMinify nicht simuliert

Der Validator spricht nicht mit einem GitLab-Runner, ruft die CI-Lint-API nicht auf und expandiert keine Remote-Includes. Erwähnungen von rules: sind ein echtes GitLab-Thema — kein Browser-Feature.

Kein Ausführen von script, kein Docker-Image, kein Runner-Cache

Keine Expansion von include: remote / include: project — 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 + rules bleiben GitLab CI Lint, nicht FastMinify

Anatomie einer .gitlab-ci.yml: was FastMinify prüft

Die Mindestform einer GitLab-CI-Config

Die Wurzel muss ein YAML-Mapping sein, kein Skalar und keine Liste. Ein Dokument: 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: er 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

Job nur mit extends: Warnung — 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 nach erfolgreichem Parse

Formatieren: js-yaml-Roundtrip, Kommentare weg

Der Formatter pretty-printet über js-yaml. Das ist kein semantischer Rewriter: Key-Reihenfolge kann sich ändern, #-Kommentare verschwinden, 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

Einfügen, Upload oder Sample: Auto-Format; nach manueller Edit den Format-Button (⌘↵)

Einzug 2 oder 4 Leerzeichen (Standard 2) — js-yaml-Dump, nicht Prettier

Kommentare werden nicht erhalten — vorher kopieren, wenn die Datei davon abhängt

Format → Validate verketten für lesbares Review und solide Struktur

YAML außerhalb von GitLab CI: beautify-yaml

include, rules und das 512-KiB-Limit

Ein Top-Level-include reicht, um die Warnung „keine Jobs“ zu vermeiden. FastMinify lädt inkludierte Dateien nicht. Über 512 KiB UTF-8 wird die Eingabe abgelehnt — wie bei den anderen DevOps-Tools.

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

Remote-Includes bleiben undurchsichtig — GitLab CI Lint merged sie, der Browser nicht

rules: im eingefügten YAML werden nicht interpretiert

Leere Eingabe bleibt idle, nicht „ungültig“

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

Validieren, dann formatieren: ein konkreter Ablauf

Den GitLab-CI-Validator nutzen

Öffnen Sie den GitLab-CI-Validator, fügen Sie eine einzelne .gitlab-ci.yml ein (max. 512 KiB) und warten Sie auf Debounce (~300 ms). Das Panel zeigt Verdict, Issues (Parse-Fehler mit Zeilenhinweis) und Zähler für Jobs / Stages / Includes.

Checks: Root-Mapping, stages-Array, Jobs mit script oder trigger, include, Hidden Jobs .

Kein Runner, kein offizielles CI-Lint-Schema, keine Remote-Include/rules-Expansion

Nur extends: Warnung; Job ohne script und trigger: Fehler

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

YAML vor der Merge Request formatieren

Der GitLab-CI-Formatter pretty-printet über js-yaml. Einfügen, Upload oder Sample: Auto-Format; nach manueller Edit den Format-Button. Dieser Schritt beweist nicht, dass die Struktur vollständig ist.

Job-Template oder schlecht eingerücktes Doc-Snippet ausrichten

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

Format → Validate verketten für lesbares Review und solide Struktur

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

Szenario — 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 im MR-Overlay schwer lesbar ist.

Schritt 1: Datei in validate-gitlab-ci einfügen

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

Schritt 2: script oder trigger ergänzen

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

Schritt 3: formatieren und MR öffnen

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

Szenario — YAML aus einem Ticket, kaputter Einzug

Ein Beispiel aus der GitLab-Doku oder einem Snippet kommt mit gemischten Spaces. Sie sehen nicht mehr, wo ein Job endet.

Schritt 1: zuerst formatieren, wenn die Datei unlesbar ist

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

Schritt 2: das eingerückte Dokument validieren

Die Ausgabe in den Validator kopieren. stages, jeden Job prüfen, und dass .-Templates keinen kaputten sichtbaren Job verdecken.

Schritt 3: CI Lint für Includes und rules behalten

Sobald die Form stimmt, bleiben Schema / Remote-Includes / rules: bei GitLab — FastMinify ersetzt dieses Gate nicht.

GitLab CI Lint (und Minify) in der Kette behalten

glab ci lint — das Schema-Netz vor dem Push

Der Browser ist die schnelle Schleife: YAML plus Struktur. GitLab lehnt eine Pipeline bereits ab, wenn das offizielle Schema ungültig ist — deshalb steckt selten ein „Lint-CI“-Job in derselben Datei. Lokal ruft glab ci lint (offizielle CLI, am Projekt authentifiziert) CI Lint auf: gemergte Includes, optional --dry-run. glab-Version pinnen; FastMinify ersetzt diesen Aufruf nicht. JS/CSS in der Pipeline minifizieren: 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 Repo auf GitHub, sind die Pendants format-github-actions und validate-github-actions — dieselbe Idee (YAML plus Struktur, nicht actionlint). Dockerfile und Compose bleiben im DevOps-Hub. Ein minifiziertes JS-Bundle aus einem Job liest man mit unminify-js oder dem Unminify-Leitfaden — das ist kein CI-YAML.

Fazit

Fügen Sie die .gitlab-ci.yml ein, korrigieren Sie die Struktur (Mapping, stages, Jobs mit script/trigger), rücken Sie ein, dann pushen. 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 UI, der API oder glab ci lint. Für generisches YAML bei beautify-yaml bleiben; für GitHub Actions im selben CI/CD-Hub.

Jetzt eine .gitlab-ci.yml validieren oder formatieren

Struktur vor jeder MR prüfen, die .gitlab-ci.yml anfasst

Für Reviews formatieren, aber YAML-Kommentare als verloren einplanen

Ein FastMinify-Verdict nicht als CI-Lint-Grünlicht behandeln

Remote-Includes und rules: in glab / Pipeline Editor lassen

Validate → Format verketten, dann glab ci lint vor dem Push