01
Remplacer les valeurs de démonstration
push et main ne décrivent pas votre projet. Pour une merge request, modifiez d’abord la source du pipeline et les branches.
Outils CI/CD
éditeur GitLab CI : comprendre les règles avant le push
Collez .gitlab-ci.yml, choisissez un contexte de test et examinez jobs, références de variables et includes locaux fournis.
éditeur GitLab CI
YAML CI
Résultat
L’analyse reste dans ce navigateur. Rien n’est envoyé à GitLab.
Pas encore analysé. Lancez l’analyse de ce YAML.
Un YAML correct peut contenir un stage mal nommé ou une règle qui écarte le job attendu. L’éditeur GitLab CI montre les indices disponibles avant de multiplier les commits de correction.
La validation YAML GitLab CI proposée ici couvre un ensemble défini de structures. Le CI Lint du projet reste nécessaire pour vérifier le comportement réel de votre instance.
Pourquoi utiliser cet éditeur GitLab CI
Séparer un job ignoré d’un job impossible à décider.
Une décision expliquée
L’éditeur GitLab CI classe chaque job comme inclus, ignoré ou indéterminé selon le contexte saisi. Sans diff, rules:changes reste indéterminé, jamais interprété comme faux.
Des includes locaux explicites
Ajoutez le chemin exact et le contenu d’un include:local pour examiner ses jobs. Un fichier absent est signalé au lieu d’être remplacé par une configuration vide.
Vérifier le contexte avant la conclusion
02
Fournir les fichiers nécessaires
Un include:local demande le même chemin et son YAML. Le navigateur ne peut pas parcourir votre dépôt ni récupérer un modèle distant.
03
Lire trois types de résultats
Analyse YAML, diagnostics de structure et aperçu des règles répondent à des questions différentes. Après un changement, relancez avec Ctrl/Cmd+Enter.
Les indices utiles au même endroit
Formatage sans écraser la source
Pour formater .gitlab-ci.yml, la sortie utilise deux espaces et conserve les commentaires représentables, tandis que l’entrée reste intacte.
Contrôles de structure ciblés
La validation YAML GitLab CI vérifie stages, action du job, forme de rules et références needs locales, sans prétendre couvrir tout le schéma serveur.
Aperçu des conditions
Le test des règles GitLab CI suit la première condition if correspondante. Les conditions qui exigent des fichiers demeurent indéterminées. Sont pris en charge la présence d’une variable, ==, !=, &&, || et les parenthèses ; les regex restent indéterminées.
Définitions et références
Les variables GitLab CI et leurs références $NAME sont listées ensemble ; une valeur peut encore provenir des paramètres du projet.
Ce que le navigateur ne peut pas prouver
- Pas de simulation serveur
- L’éditeur GitLab CI ne crée pas de pipeline et n’exécute pas les scripts. Les permissions et la version de GitLab doivent être vérifiées dans CI Lint.
- Pas de diff, pas de décision
- rules:changes et rules:exists nécessitent l’état du dépôt. Une information absente n’est pas transformée en condition fausse.
- Includes fournis uniquement
- include:local est résolu avec un chemin exact fourni. project, remote, template et component ne sont pas téléchargés.
- Variables extérieures invisibles
- Une référence non définie localement peut être renseignée par le projet, le groupe ou l’instance.
- Source préservée
- Le formatage produit une sortie distincte. Comparez-la à l’entrée avant de copier ou de télécharger.
Questions sur l’éditeur GitLab CI
Comment valider .gitlab-ci.yml avant un push ?
Passez le brouillon dans l’éditeur GitLab CI pour les contrôles pris en charge, puis utilisez le CI Lint de votre projet avant le push.
Pourquoi une règle GitLab CI ne sélectionne-t-elle pas le job ?
L’aperçu local évalue les expressions if prises en charge. La simulation GitLab dispose aussi de la branche, des needs et du dépôt réel.
Pourquoi include:local ne trouve-t-il pas le fichier ?
Saisissez le chemin include:local exact et collez le contenu du fichier. Un fichier manquant reste non résolu ; le dépôt n’est pas lu automatiquement.
Les variables d'un job sont-elles disponibles dans rules:if ?
Les variables du job ne sont pas nécessairement disponibles au moment où GitLab évalue rules. Vérifiez leur portée dans la documentation.
Comment repérer les variables référencées par le YAML ?
L’onglet Variables regroupe les références $NAME et les définitions locales. Une absence locale ne prouve pas une absence dans GitLab.
Un workflow que cet outil juge mal ?
Essayer l’éditeur GitLab CI sur un brouillon
Revenez à l’éditeur GitLab CI pour examiner les incertitudes, puis validez le fichier final dans le projet GitLab.