Ce que fait ce générateur
Un .gitlab-ci.yml vit à la racine de votre repo GitLab et décrit le pipeline complet : stages ordonnés (install, test, deploy), jobs individuels avec leurs scripts, ce qu'il faut cacher et ce qu'il faut publier comme artifacts, et quand chaque job tourne vraiment (seulement sur main ? seulement sur les tags ? seulement quand un fichier a changé ?). C'est un fichier, pas d'UI séparée, versionné avec le reste du code.
Ce générateur écrit ce fichier pour vous. Choisissez un preset (test + deploy, push Docker registry, GitLab Pages), éditez les stages et jobs dans des formulaires, et le panneau de droite montre le YAML exact que vous pouvez mettre dans `.gitlab-ci.yml`. Le validateur vérifie les pièges courants : un job qui a besoin d'un autre job dans un stage plus tard, un job référençant un stage qui n'est pas dans la liste `stages:`, des noms de job dupliqués, des jobs sans script.
Tout tourne dans votre navigateur. Pas d'upload, pas de compte, aucun vrai pipeline n'est démarré ici. La sortie est le même texte que vous écririez à la main.
Mode d'emploi
- Choisissez un preset en haut : Test + deploy, push Docker registry, ou GitLab Pages. Le formulaire remplit des défauts sensés.
- Réglez l'image par défaut (utilisée par chaque job qui ne l'override pas), la liste ordonnée des stages, et toute variable globale comme paires `KEY=value`.
- Ajoutez des jobs dans les onglets. Pour chaque job réglez : un nom unique, le stage auquel il appartient (doit matcher un de la liste stages), un override d'image optionnel, des variables optionnelles, et needs.
- Écrivez le script (une commande par ligne). Optionnellement ajoutez un before_script pour les commandes de setup partagées à travers les runs.
- Réglez les artifacts (paths et `expire_in`) pour la sortie de build. Réglez le cache avec une clé et des paths pour accélérer les runs répétés.
- Ajoutez des rules avec des expressions `if:`, par exemple `$CI_COMMIT_BRANCH == "main"`. Choisissez `on_success`, `always`, `manual` (demande un clic pour démarrer), ou `never`.
- Basculez allow_failure pour les jobs qui ne devraient pas bloquer le pipeline s'ils échouent (linters, scanners sécu qui sont consultatifs).
- Cliquez sur Copier dans le panneau d'aperçu, ou Télécharger pour sauvegarder comme `.gitlab-ci.yml`, puis commitez à la racine de votre repository. Le prochain push déclenche le pipeline.
Quand cet outil est utile
Sept situations concrètes où un générateur GitLab CI fait gagner du vrai temps :
- Premier pipeline dans un nouveau projet. Choisissez "Test + deploy", changez la commande de test, commitez. Fini en deux minutes au lieu de pêcher dans la longue doc GitLab.
- Ajouter un push Docker registry à un pipeline existant. La danse login + tag + push est une séquence connue ; le générateur l'écrit et vous remplissez juste le nom d'image.
- Mettre en place un job de déploiement qui ne tourne que sur main. La syntaxe `rules:` avec `if:` est la voie moderne (remplaçant les anciens `only:` / `except:`), et de petites fautes gaspillent un run de pipeline complet.
- Cacher node_modules ou pip à travers les runs de pipeline. La strophe cache est courte mais facile à mal formater. Le générateur écrit un cache fonctionnel par défaut avec la clé standard `$CI_COMMIT_REF_SLUG`.
- Pipeline multi-stages avec des jobs parallèles en test. Plusieurs jobs dans le stage `test` tournent en parallèle automatiquement. Le générateur rend la structure évidente pour que vous ne les sérialisiez pas accidentellement.
- Une gate de déploiement manuelle. Réglez la règle du job deploy à `when: manual` et seul un clic explicite dans l'UI GitLab démarre le déploiement. Pattern courant pour la prod.
- Déploiement de site GitLab Pages. Le job spécial `pages` doit publier vers `public/` comme artifact. Le preset "Pages deploy" encode cette convention exactement.