GitLab CI : formater et valider votre .gitlab-ci.yml en…

Pourquoi contrôler un .gitlab-ci.yml avant que la pipeline ne tourne ?

Un .gitlab-ci.yml qui ne parse pas, un stages qui n'est pas un tableau, ou un job sans script ni trigger, se voit souvent trop tard : pastille rouge, Pipeline Editor, merge bloqué. FastMinify n'embarque pas le CI Lint officiel de GitLab et n'exécute aucun runner. Le validateur GitLab CI fait des contrôles structurels dans le navigateur — mapping racine, stages, jobs avec script ou trigger, include, jobs cachés . — et le formateur GitLab CI réindente le YAML (2 ou 4 espaces). Le cluster complet est sur le hub outils CI/CD. Pour minifier JS/CSS dans la même pipeline, voir le guide minification CI/CD.

Repérer un YAML invalide, un stages mal typé ou un job sans script/trigger avant le push

Formater l'indentation 2 ou 4 espaces pour une revue lisible

100 % dans le navigateur — le fichier n'est jamais envoyé

Plafond 512 Kio UTF-8, comme les autres outils DevOps du site

Garder GitLab CI Lint (includes distants, rules, schéma officiel) pour glab et l'UI

GitLab vs GitHub Actions : deux YAML, trois couches

Un fichier racine, pas un dossier workflows

GitHub Actions vit sous .github/workflows/*.yml (plusieurs fichiers, déclencheur on, jobs avec steps). GitLab CI vit presque toujours dans un seul .gitlab-ci.yml à la racine : stages, jobs nommés, include. Les outils FastMinify suivent cette frontière — ne collez pas un workflow Actions dans le validateur GitLab.

GitLab : un document YAML, jobs au premier niveau (sauf clés réservées)

GitHub : map jobs imbriquée + on obligatoire — voir le guide GitHub Actions

Dockerfile et Compose restent sur le hub DevOps

Pour du YAML générique (pas CI), utilisez beautify-yaml

Un artefact JS minifié d'une job n'est pas du CI YAML : unminify-js

Formater, valider, CI Lint : trois couches, pas un seul bouton

FastMinify expose deux outils. Ni l'un ni l'autre n'est GitLab CI Lint. Confondre les trois mène à un fichier « valide » ici qui échoue quand même dans Pipeline Editor.

Formater : round-trip js-yaml, indentation 2 ou 4 espaces (défaut 2) — voir format-gitlab-ci

Valider : parse YAML + structure (mapping, stages, jobs, include) — voir validate-gitlab-ci

GitLab CI Lint : schéma officiel, expansion des include, évaluation des rules: — UI Pipeline Editor, API, ou glab ci lint

Les commentaires YAML sont supprimés au formatage (même limite que beautify-yaml) — gardez une copie si vous en dépendez

Un verdict « structure OK » ne prouve pas qu'un include distant existe ni qu'une règle rules: sélectionne le job

Ce que FastMinify ne simule pas

Le validateur ne parle pas au runner GitLab, n'appelle pas l'API CI Lint, et n'étend pas les includes distants. Les rules: du calendrier éditorial sont un sujet GitLab réel — pas une feature du navigateur.

Pas d'exécution de script, pas d'image Docker, pas de cache runner

Pas d'expansion include: remote / include: project — seul le YAML collé est lu

Pas d'évaluation rules:, only/except, workflow:rules

Les jobs pages sont des jobs comme les autres : ils ont besoin de script ou trigger

Le filet schéma + includes + rules reste GitLab CI Lint, pas FastMinify

Anatomie d'un .gitlab-ci.yml : ce que FastMinify vérifie

La forme minimale d'une config GitLab CI

La racine doit être un mapping YAML, pas un scalaire ni une liste. Un seul document : les --- répétés sont rejetés. Si stages est présent, ce doit être un tableau de noms non vides. Chaque clé qui n'est pas réservée et ne commence pas par . est un job : il lui faut script (chaîne ou liste non vide) ou trigger.

Clés réservées (pas des jobs) : stages, variables, include, workflow, default, image, services, cache, before_script, after_script, spec

Jobs cachés / templates .hidden : pas d'exigence script

Job avec seulement extends : avertissement — le parent doit fournir script ou trigger

Aucun job et aucun include de premier niveau : avertissement, pas forcément un blocker

Le panneau compte jobs, stages et includes après un parse réussi

Formater : round-trip js-yaml, commentaires perdus

Le formateur pretty-print via js-yaml. Ce n'est pas un réécrivain sémantique : l'ordre des clés peut changer, les commentaires # disparaissent, l'indentation passe à 2 ou 4 espaces.

Avant

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

Après

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

Collage, upload ou sample : format automatique ; après une édition manuelle, bouton Formater (⌘↵)

Indentation 2 ou 4 espaces (défaut 2) — le moteur dump js-yaml, pas Prettier

Les commentaires sont non conservés — copiez-les d'abord si le fichier en dépend

Enchaînez format → validate pour une revue lisible et une structure saine

YAML hors GitLab CI : beautify-yaml

include, rules et le plafond 512 Kio

Un include de premier niveau suffit à éviter l'avertissement « aucun job ». FastMinify ne télécharge pas les fichiers inclus. Au-delà de 512 Kio UTF-8, l'entrée est rejetée — comme les autres outils DevOps du site.

Compteur include : une entrée scalaire compte 1 ; un tableau compte sa longueur

Les includes distants restent opaques — CI Lint GitLab les fusionne, pas le navigateur

Les rules: dans le YAML collé ne sont pas interprétées

Entrée vide : état inactif, pas « invalide »

Un document trop gros : passez par glab ci lint en local

Valider puis formater : un workflow concret

Utiliser le validateur GitLab CI

Ouvrez le validateur GitLab CI, collez un seul .gitlab-ci.yml (max 512 Kio) et attendez le debounce (~300 ms). Le panneau affiche un verdict, les issues (erreur de parse avec indice de ligne), et des compteurs jobs / stages / includes.

Contrôles : mapping racine, stages tableau, jobs avec script ou trigger, include, jobs cachés .

Pas de runner, pas de schéma CI Lint, pas d'expansion include/rules distante

extends seul : warning ; job sans script ni trigger : erreur

Tout reste local — pas de compte, pas d'upload vers un serveur FastMinify

Formater le YAML avant la merge request

Le formateur GitLab CI pretty-print via js-yaml. Collage, upload ou sample : format automatique ; après une édition manuelle, utilisez le bouton Formater. Cette étape ne prouve pas que la structure est complète.

Alignez un template de job ou un extrait de doc mal indenté

Les commentaires # disparaissent au round-trip — copiez-les d'abord si besoin

Enchaînez format → validate pour une revue lisible et une structure saine

Pour du YAML hors GitLab CI, utilisez beautify-yaml plutôt que cet outil

Scénario — job sans script ni trigger

Un collègue a ajouté compile: avec seulement stage: build. GitLab refuse la pipeline, souvent avec un message peu lisible dans l'overlay de MR.

Étape 1 : coller le fichier dans validate-gitlab-ci

Ouvrez validate-gitlab-ci. Un verdict invalide du type « Job … needs script or trigger » pointe le job vide.

Étape 2 : ajouter script ou trigger

Ajoutez script: [npm run build] ou un trigger: réel. Recollez jusqu'à ce que le panneau affiche une structure valide (les warnings extends peuvent rester).

Étape 3 : formater et ouvrir la MR

Passez le YAML corrigé dans format-gitlab-ci, copiez, commitez. Les reviewers lisent des jobs indentés, pas un blob.

Scénario — YAML collé depuis un ticket, indentation cassée

Un exemple copié depuis la doc GitLab ou un snippet arrive avec un mélange d'espaces. Vous ne voyez plus où finit un job.

Étape 1 : formater d'abord si le fichier est illisible

Collez dans format-gitlab-ci. Cette étape ne prouve pas que la config est structurellement complète.

Étape 2 : valider le document indenté

Copiez la sortie dans le validateur. Vérifiez stages, chaque job, et que les templates . ne masquent pas un job visible cassé.

Étape 3 : garder CI Lint pour includes et rules

Une fois la forme OK, le filet schéma / includes distants / rules: reste dans GitLab — FastMinify ne le remplace pas.

Garder GitLab CI Lint (et minify) dans la chaîne

glab ci lint — le filet schéma avant le push

Le navigateur sert la boucle rapide : YAML + structure. GitLab refuse déjà de créer une pipeline si le schéma officiel est invalide — c'est pourquoi on n'embarque généralement pas un job « lint CI » dans le même fichier. En local, glab ci lint (CLI officielle, authentifiée sur le projet) appelle CI Lint : includes fusionnés, simulation possible avec --dry-run. Pinnez votre version de glab ; FastMinify ne remplace pas cet appel. Pour minifier JS/CSS dans la pipeline, voir le guide minification CI/CD.

Exemple de base

# 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

Si le dépôt est sur GitHub, les pendants sont format-github-actions et validate-github-actions — même idée (YAML + structure, pas actionlint). Dockerfile et Compose restent sur le hub DevOps. Un bundle JS minifié produit par une job se lit avec unminify-js ou le guide unminify — ce n'est pas du YAML CI.

Conclusion

Collez le .gitlab-ci.yml, corrigez la structure (mapping, stages, jobs avec script/trigger), reformatez l'indentation, puis poussez. FastMinify fait cette boucle en local, sans envoyer le YAML. Ce n'est pas GitLab CI Lint : includes distants, rules: et le schéma officiel restent dans l'UI, l'API ou glab ci lint. Pour du YAML générique, restez sur beautify-yaml ; pour GitHub Actions, sur le même hub CI/CD.

Validez ou formatez un .gitlab-ci.yml maintenant

Validez la structure avant chaque MR qui touche .gitlab-ci.yml

Formatez pour la revue, mais attendez-vous à perdre les commentaires YAML

Ne traitez pas un verdict FastMinify comme un feu vert CI Lint

Gardez includes distants et rules: dans glab / Pipeline Editor

Enchaînez validate → format, puis glab ci lint avant le push

GitLab CI : formater et valider votre .gitlab-ci.yml en ligne