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

Stages, includes, règles `rules:` : validez la structure d'un .gitlab-ci.yml avant la pipeline — pas un runner GitLab, pas le CI Lint officiel.

29.08.2026

9 min de lecture

Partager cet article:

GitLab CIYAMLCI/CDDevOps

Contrôler un .gitlab-ci.yml avant que le pipeline ne tourne

Un .gitlab-ci.yml qui ne s'analyse pas, un stages qui n'est pas un tableau ou un job sans script ni trigger se voit souvent trop tard. Vous voyez alors une pastille rouge dans le Pipeline Editor et une fusion bloquée. 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 .). Le formateur GitLab CI remet l'indentation du YAML sur 2 ou 4 espaces. Toute la famille d'outils se trouve sur le hub outils CI/CD. Pour minifier le JS et le CSS dans le même pipeline, voir le guide minification CI/CD.

Repérer un YAML invalide, une valeur stages de mauvais type ou un job sans script ni trigger avant le push

Formater avec une indentation de 2 ou 4 espaces pour une relecture lisible

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

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

Laisser GitLab CI Lint (includes distants, rules, schéma officiel) à glab et à l'interface

GitLab et GitHub Actions, deux formes de YAML et 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, donc 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 plus on obligatoire, voir le guide GitHub Actions

Dockerfile et Compose restent sur le hub DevOps

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

Un artefact JS minifié produit par un job n'est pas du YAML de CI : unminify-js

Formater, valider et CI Lint sont trois couches, pas un seul bouton

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

Formater : aller-retour js-yaml avec une indentation de 2 ou 4 espaces (2 par défaut), voir format-gitlab-ci

Valider : analyse du YAML plus structure (mapping, stages, jobs, include), voir validate-gitlab-ci

GitLab CI Lint : schéma officiel, expansion des include et évaluation des rules:, via l'interface du Pipeline Editor, l'API ou glab ci lint en local

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

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. La clause rules: est une vraie fonctionnalité de GitLab, et le navigateur ne l'évalue pas.

Aucune exécution de script, aucune image Docker, aucun cache du runner

Aucune expansion de include: remote ni de include: project : seul le YAML collé est lu

Aucune évaluation de rules:, de only/except ni de workflow:rules

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

Le schéma, les includes et les rules restent du ressort de GitLab CI Lint, pas de FastMinify

Ce que FastMinify vérifie dans l'anatomie d'un .gitlab-ci.yml

La forme minimale d'une config GitLab CI

La racine doit être un mapping YAML, pas un scalaire ni une liste. Il n'y a qu'un seul document, et 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, et 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

Un job avec seulement extends reçoit un avertissement, car le parent doit fournir script ou trigger

Aucun job et aucun include de premier niveau : avertissement, pas forcément une erreur bloquante

Le panneau compte les jobs, les stages et les includes une fois l'analyse réussie

Formater est un aller-retour js-yaml, et les commentaires sont perdus

Le formateur réécrit le YAML via js-yaml. Ce n'est pas un outil de réécriture sémantique : l'ordre des clés peut changer, les commentaires # disparaissent, et l'indentation est ramenée à 2 ou 4 espaces.

Avant

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

Après

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

Collez, importez ou chargez l'exemple : le formatage est automatique, et après une modification manuelle, utilisez le bouton Formater (⌘↵)

Indentation de 2 ou 4 espaces (2 par défaut) produite par le dump de js-yaml, pas par Prettier

Les commentaires ne sont pas 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 pour 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 de GitLab les fusionne alors que le navigateur ne le fait pas

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

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

Un fichier trop volumineux : passez par glab ci lint en local

Valider puis formater, un enchaînement concret

Utiliser le validateur GitLab CI

Ouvrez le validateur GitLab CI, collez un seul .gitlab-ci.yml (512 Kio au plus) et attendez le debounce (~300 ms). Le panneau affiche un verdict, les problèmes (erreur d'analyse avec indication de ligne) et des compteurs de jobs, de stages et d'includes.

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

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

Un job avec extends seul donne un avertissement, un job sans script ni trigger donne une erreur

Tout reste local, sans compte et sans envoi vers un serveur FastMinify

Formater le YAML avant la demande de fusion

Le formateur GitLab CI réécrit le YAML via js-yaml. Collez, importez ou chargez l'exemple, et le formatage se fait tout seul. Après une modification manuelle, utilisez le bouton Formater. Cette étape ne prouve pas que la structure est complète.

Remettez au propre un modèle de job ou un extrait de documentation mal indenté

Les commentaires # disparaissent à l'aller-retour : 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

Un job sans script ni trigger

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

Collez le fichier dans validate-gitlab-ci

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

Ajoutez script ou trigger

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

Formatez et ouvrez la MR

Passez le YAML corrigé dans format-gitlab-ci, copiez-le et faites le commit. Les relecteurs lisent des jobs indentés, pas un bloc d'une seule ligne.

Un YAML collé depuis un ticket, à l'indentation cassée

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

Formatez d'abord si le fichier est illisible

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

Validez le document indenté

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

Gardez CI Lint pour les includes et les rules

Une fois la forme correcte, le contrôle du schéma, des includes distants et de rules: reste dans GitLab : FastMinify ne le remplace pas.

Gardez GitLab CI Lint (et la minification) dans la chaîne

glab ci lint, le filet de sécurité du schéma avant le push

Le navigateur sert à la boucle rapide pour le YAML et sa structure. GitLab refuse déjà de créer un 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 (la CLI officielle, authentifiée sur le projet) appelle CI Lint avec les includes fusionnés et une simulation possible via --dry-run. Épinglez votre version de glab, car FastMinify ne remplace pas cet appel. Pour minifier le JS et le CSS dans le 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 équivalents sont format-github-actions et validate-github-actions, avec la même idée : du YAML plus de la structure, sans actionlint. Dockerfile et Compose restent sur le hub DevOps. Un bundle JS minifié produit par un job se lit avec unminify-js ou le guide unminify, et ce n'est pas du YAML de CI.

Conclusion

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

Validez ou formatez un .gitlab-ci.yml maintenant

Valider GitLab CI Formater GitLab CI Valider GitHub Actions Hub outils CI/CD

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

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

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

Confiez à glab / Pipeline Editor les includes distants et rules:

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

Partager cet article

Partager cet article:

Articles connexes

Calculateur de sous-réseau CIDR : calculer, agréger des plages et tester une IP

Calculez réseau, masque, plage d’hôtes et broadcast d’un CIDR, agrégez des plages en blocs minimaux et testez une IP, directement dans votre navigateur.

11.10.202618 min de lecture

Inspecter une requête HTTP : curl, message brut et HAR

Formatez un Copy as cURL, analysez une requête ou une réponse HTTP brute et lisez un export HAR dans votre navigateur : rien n’est envoyé ni rejoué.

07.10.202618 min de lecture

JWT encode/decode : fabriquer et inspecter un token en ligne

Décodez l'en-tête et le payload d'un JWT ou signez un token de test dans votre navigateur : HS256, RS256, ES256, sans envoyer de secret à un tiers.

04.10.202618 min de lecture