Valider gitlab-ci.yml en ligne, avant le runner.

Collez votre .gitlab-ci.yml dans ce validateur GitLab CI YAML et il l’analyse instantanément. Il fait deux choses à la fois. D’abord, il signale les erreurs de syntaxe YAML, les mauvaises indentations et les erreurs structurelles, avec la ligne qui a échoué. Ensuite, il exécute des contrôles de mauvaise configuration de pipeline qui correspondent à la façon dont GitLab lui-même valide une configuration : un job sans script / run / trigger / extends, un job dont le stage n’est pas dans votre liste stages, des références needs et extends pointant vers des jobs qui n’existent pas, une valeur when invalide, un bloc rules qui n’est pas une liste, l’ancien only/except, et des formes image/services incorrectes. Vous obtenez les erreurs YAML et les erreurs de pipeline en une seule passe.

Oui. Vous pouvez vérifier un pipeline GitLab sans projet, sans connexion et sans runner : ce linter GitLab CI s’exécute à 100 % côté client. Votre .gitlab-ci.yml est analysé à l’intérieur de votre onglet de navigateur — rien n’est envoyé à un serveur, et il n’y a ni compte ni inscription. Vous pouvez coller en toute sécurité des pipelines internes ou propriétaires, y compris ceux contenant des étiquettes de runner privées, des noms d’image internes et des références à des variables secrètes.

Ce message signifie que GitLab a refusé votre configuration, soit pour une erreur de syntaxe YAML, soit pour une mauvaise configuration structurelle du pipeline. Les causes les plus fréquentes : un job dont le stage n’est pas déclaré dans stages:, un job sans script / run / trigger / extends, une référence needs ou extends vers un job qui n’existe pas, une valeur when invalide, ou un bloc rules: qui n’est pas écrit comme une liste. Ce validateur reproduit ces mêmes contrôles pour vous aider à vérifier les erreurs de .gitlab-ci.yml et à trouver la ligne fautive avant de pousser.

Collez le YAML du pipeline dans ce validateur basé sur le navigateur pour vérifier les erreurs de .gitlab-ci.yml avant de valider — aucune installation ni aucun push nécessaires. L’outil exécute l’ensemble complet des contrôles (structure YAML plus mauvaises configurations de pipeline) entièrement dans votre navigateur, vous obtenez donc un retour instantané sur les erreurs de syntaxe, les stages non déclarés, les jobs sans script, les needs/extends cassés et les valeurs when invalides avant que la configuration n’atteigne un runner GitLab.

Oui — c’est exactement ce que propose cet outil. C’est un validateur GitLab CI YAML gratuit qui fonctionne en ligne, dans le navigateur, sans compte, sans inscription et sans connexion. L’éditeur de pipeline et CI Lint de GitLab sont excellents et font autorité — ils résolvent les includes, les variables de projet et le schéma en direct, et vous devriez les utiliser avant de fusionner — mais ils nécessitent un projet GitLab, une connexion et un aller-retour avec le serveur. Ici, vous obtenez un retour instantané et hors ligne sur les erreurs structurelles à fort signal pendant que vous êtes encore en train d’éditer. Considérez un résultat propre ici comme une forte confiance avant le push, puis confirmez avec CI Lint.

Au-delà de la validité du YAML, le validateur exécute une série de contrôles structurels. Un job visible doit faire quelque chose : exécuter des commandes avec script: (ou le plus récent run:), démarrer un pipeline en aval avec trigger:, ou hériter de l’un de ceux-ci via extends:. Il résout ensuite vos stages — la liste stages: déclarée, ou les cinq valeurs par défaut .pre, build, test, deploy et .post — et vérifie le stage de chaque job par rapport à cet ensemble. Il contrôle aussi que les références needs, dependencies et extends pointent vers des jobs réels, que when: vaut on_success, on_failure, always, manual, delayed ou never, que rules: est bien une liste, et il signale l’ancien only/except à titre informatif.

Cette erreur YAML signale presque toujours un problème d’indentation ou un deux-points mal placé : une clé enfant alignée au même niveau que sa clé parente, un onglet de tabulation au lieu d’espaces, ou un tiret de liste manquant. Le lecteur YAML s’attendait à trouver une clé là où il a rencontré autre chose. Le validateur vous donne la ligne exacte qui a échoué afin que vous puissiez réaligner l’indentation. Réindentez avec deux espaces de manière cohérente, n’utilisez jamais de tabulations, et collez à nouveau pour confirmer que l’erreur a disparu.

GitLab rejette un job visible qui ne définit aucune action exécutable. Un job ordinaire exécute des commandes avec script: (ou run:), un job de type bridge démarre un pipeline en aval avec trigger:, et un job peut hériter de l’un de ceux-ci depuis un autre job ou un template masqué via extends:. Un job visible qui n’en définit aucun est rejeté avec une erreur du type « job config should implement a script: or a trigger: keyword ». Le validateur signale tout job visible auquel manquent ces quatre éléments. Les templates masqués (clés commençant par un point) sont autorisés à être des fragments partiels ; ils ne sont donc pas tenus d’avoir un script.