Outils CI/CD

validateur GitHub Actionsformatage, validation et navigation dans chaque job

Collez un workflow YAML pour le formater, parcourir l'arbre job/step et prévisualiser un brouillon de matrix ou de cron avant de l'insérer.

Validation automatique

YAML du workflow

Résultat

Tout est traité dans le navigateur, rien n'est envoyé à GitHub ni à un serveur.

OptionsIndentation

Générateur de matrice (brouillon)

Variables

include (optionnel)

exclude (optionnel)

fail-fastmax-parallel (optionnel)Insérer dans le job

Générez un aperçu pour voir l'extrait strategy.matrix.

Générateur de planification cron (brouillon)

Expression cron (5 champs)Fuseau horaire (optionnel)

Générez un aperçu pour voir l'extrait on.schedule.

En attente de validation…

Un fichier workflow YAML pour GitHub Actions casse le plus souvent après le push — un job sans runs-on, une valeur permissions qui n'existe pas dans l'énumération réelle, ou une planification qui ne se déclenche jamais silencieusement. Ce validateur GitHub Actions repère ce type d'erreur localement, avant même qu'un run ne démarre, en vérifiant la structure dont la CI dépend réellement, pas seulement une syntaxe YAML générique.

Utile quand un workflow avec plusieurs jobs est modifié à la main et qu'il faut retrouver rapidement celui qui casse, quand une matrice de build est construite sur plusieurs systèmes et versions, quand des références env, secrets et vars doivent être suivies à travers plusieurs steps, ou quand une expression cron dans on.schedule est écrite et qu'il faut savoir ce que GitHub Actions autorise vraiment.

Pourquoi utiliser ce validateur GitHub Actions

Un seul espace de travail au lieu de jongler entre un linter YAML générique, un générateur de matrice et un outil cron qui ignore tout de GitHub Actions.

Formatage, validation de structure et navigation job/step réunis

Un workflow collé est formaté, les id de job et de step sont vérifiés selon la règle de nommage, chaque job est contrôlé pour avoir runs-on ou uses, les valeurs permissions sont validées contre leur véritable énumération (id-token n'accepte que write ou none), et les filtres exclusifs comme branches et branches-ignore utilisés ensemble sont signalés — puis un arbre job/step cliquable fait sauter l'éditeur directement à la bonne ligne.

Voir les règles et limites

Workflow YAML GitHub Actions formaté à côté d'un arbre de navigation job/step cliquable avec une erreur de structure mise en évidence

Voir exactement où les références env, secrets et github vont casser

Le panneau de références liste chaque expression ${{ env.X }}, ${{ secrets.X }}, ${{ vars.X }} et ${{ github.X }} trouvée, avec le job et le step concernés, et signale les trois emplacements d'échec documentés : env ne peut pas être utilisé dans l'id ou le uses d'un step, secrets ne peut pas être lu directement dans une condition if:, et github ne peut pas être utilisé dans uses:.

Voir comment les références sont extraites

Liste des références env, secrets, vars et github avec trois entrées signalées aux endroits où GitHub Actions rejette réellement l'expression

Un générateur cron qui connaît déjà les limites propres à GitHub Actions

Le panneau cron construit une expression standard à cinq champs et applique les contraintes documentées par GitHub pour les déclencheurs schedule : intervalle minimum de cinq minutes, UTC par défaut avec un fuseau IANA optionnel, aucun alias de type @daily, et la désactivation automatique après 60 jours d'inactivité sur un dépôt public.

Lire la FAQ sur la planification

Générateur cron affichant l'intervalle minimum de cinq minutes, le fuseau UTC par défaut et un avertissement d'alias non pris en charge par GitHub Actions

Trois choses faciles à manquer à la première utilisation

L'outil fait plus, en arrière-plan, que ce que montre la barre d'outils.

Coller un workflow ou charger l'exemple

Collez un workflow YAML copié depuis votre éditeur, ou chargez l'exemple intégré — il contient déjà un déclencheur schedule, un job avec strategy.matrix et des références env/secrets/github, de quoi voir les cinq fonctionnalités d'un coup. La validation automatique est activée par défaut et se relance 350ms après l'arrêt de la saisie ; rien n'est jamais envoyé.

Cliquer sur un nom de job ou de step dans l'arbre de navigation fait sauter l'éditeur directement à cette ligne — ce qui fait vraiment gagner du temps dès qu'un workflow compte plus de quelques jobs.

Traiter les panneaux matrix et cron comme des brouillons, pas des modifications en direct

Modifier le tableau de variables de la matrice ou les champs cron ne touche jamais le workflow tout seul, cela ne génère qu'un aperçu. Rien n'est écrit dans strategy.matrix ou on.schedule tant que le bouton Insérer n'est pas cliqué, et jusque-là le brouillon peut quand même être copié seul.

Mettez les numéros de version entre guillemets, comme node-version: "3.10" — sans guillemets, YAML lit 3.10 comme le nombre 3.1 et perd silencieusement le zéro final.
fail-fast vaut true par défaut et max-parallel reste vide (illimité), comme les valeurs par défaut de GitHub Actions lui-même.

Lire les signaux de risque avant de faire confiance à un résultat propre

La liste des références env/secrets/vars/github marque les emplacements précis où GitHub Actions rejette réellement une expression, documentés comme tels — pas une supposition de linter générique. Ctrl/Cmd+Entrée relance la validation quand l'exécution automatique est désactivée ; en continuant à éditer après un résultat, copier et télécharger restent désactivés jusqu'à la revalidation, pour ne jamais exporter un résultat périmé.

Un filtre au-dessus de la liste des références permet de n'afficher que env, secrets, vars ou github à la fois, utile quand un workflow contient beaucoup d'expressions.

Ce qui se passe réellement sous le capot

Cinq fonctionnalités qui travaillent ensemble plutôt que cinq onglets séparés.

Formatage YAML avec indentation au choix

Reformate un workflow avec une indentation cohérente à deux ou quatre espaces, pour qu'un diff de pull request ne montre que les lignes réellement modifiées, pas un fichier entièrement reformaté.

Vérifications structurelles contre les vraies règles de workflow

Les id de job et de step sont vérifiés selon le motif de nommage requis, chaque job est contrôlé pour déclarer runs-on ou uses, les valeurs permissions sont comparées à leur véritable énumération, et les filtres mutuellement exclusifs comme branches et branches-ignore sont signalés quand les deux apparaissent sur le même déclencheur.

Arbre de navigation job/step cliquable

L'arbre reflète la structure job et step réelle du workflow ; sélectionner une entrée fait défiler l'éditeur jusqu'à cette ligne exacte, sans avoir à compter des niveaux d'indentation.

Générateur de matrice avec include, exclude et fail-fast

Construisez un tableau de variables du type os/version, ajoutez des combinaisons include ou exclude, réglez fail-fast et max-parallel, prévisualisez le strategy.matrix résultant, puis insérez-le dans le job choisi.

Inventaire des références env/secrets/vars/github

Chaque expression ${{ }} référençant env, secrets, vars ou github est extraite et listée par job et par step, avec un filtre pour isoler un seul de ces contextes à la fois.

Générateur de snippet cron dédié à GitHub Actions

Construisez une planification à cinq champs à partir de préréglages courants ou d'une expression personnalisée, prévisualisez l'entrée on.schedule exacte, puis insérez-la — les limites de planification propres à GitHub sont appliquées automatiquement, sans avoir à s'en souvenir.

Ce qui est vérifié, et ce qui est volontairement laissé de côté

Connaître les limites compte plus qu'une longue liste de fonctionnalités.

Rien ne se connecte à GitHub: Ce validateur GitHub Actions se contente de lire du YAML localement. Il n'appelle jamais l'API GitHub, ne fork ni ne push aucun dépôt, et ne déclenche ni n'exécute jamais un workflow — il formate et vérifie uniquement le texte collé, entièrement sur l'appareil de l'utilisateur.
Les expressions ne sont pas évaluées: ${{ github.sha }} ou ${{ steps.build.outputs.version }} sont extraites et listées, pas résolues en une véritable valeur d'exécution. Tester le comportement réel des expressions demande un moteur dédié, qui est un outil séparé — celui-ci ne le simule volontairement pas avec un eval JavaScript.
Les vérifications de schéma sont un sous-ensemble ciblé, pas actionlint: La validation structurelle couvre la partie du schéma public schemastore.org qui ne dépend pas de métadonnées externes : id de job/step, runs-on/uses, permissions, conflits de filtres. Elle ne vérifie ni les types d'entrée d'une action, ni les versions d'actions du Marketplace, ni une liste à jour des labels de runner pris en charge, car ces métadonnées deviennent obsolètes dès qu'elles sont mises en cache hors ligne.
Aucun graphe de dépendances: L'arbre job/step montre la structure, pas un DAG représentant les relations needs: entre jobs. Pour visualiser ce graphe de dépendances, il faudrait un autre type de vue, que cet outil ne propose pas encore.
Les limites de planification sont documentées, pas garanties: Le générateur cron applique les règles publiées par GitHub — cinq minutes minimum, UTC par défaut, pas d'alias de type @daily — mais ne peut pas garantir que le champ timezone optionnel soit respecté, ni qu'une planification se déclenche exactement à la minute prévue ; GitHub indique lui-même que les exécutions planifiées peuvent être retardées en cas de forte charge et désactivées après 60 jours d'inactivité du dépôt.

FAQ du validateur GitHub Actions

Des réponses fondées sur ce que GitHub documente, pas des suppositions.

Le fuseau horaire ajouté à une planification cron GitHub Actions fonctionne-t-il vraiment ?

L'entrée générée respecte la syntaxe publiée — GitHub a ajouté le support optionnel d'un fuseau IANA à schedule en 2024 — mais les discussions de la communauté GitHub elle-même contiennent des signalements réels où il n'a pas été respecté. Ce validateur garantit seulement que le snippet correspond à la syntaxe publiée, pas que le planificateur de GitHub l'applique réellement.

Pourquoi ma planification cron GitHub Actions ne s'exécute-t-elle pas à l'heure prévue ?

Plusieurs causes réelles possibles : le fichier workflow n'est pas sur la branche par défaut, le dépôt est inactif et GitHub a désactivé automatiquement la planification après 60 jours, ou l'expression utilise un intervalle inférieur au minimum documenté de cinq minutes. GitHub indique aussi que les exécutions planifiées peuvent être retardées en période de forte charge, surtout autour des heures pleines — cet outil vérifie la syntaxe cron, mais ne peut pas garantir l'heure exacte de déclenchement.

GitHub affiche seulement "you have an error in your yaml syntax" sans indiquer la ligne, comment la trouver ?

Collez le workflow dans ce validateur GitHub Actions : il indique le nom précis du job ou du step ainsi que la ligne et la colonne, au lieu du message générique de GitHub. La revalidation automatique se relance 350ms après l'arrêt de la saisie, donc l'emplacement signalé se met à jour au fil des corrections.

Pourquoi le bloc with: d'un reusable workflow affiche-t-il "Unrecognized named-value: 'env'" ?

Parce que le contexte env n'est tout simplement pas disponible dans with: — l'une des trois restrictions documentées que le panneau de références signale directement (env est aussi refusé dans l'id et le uses d'un step). Il faut placer la valeur dans un env au niveau du job ou du workflow, ou la passer explicitement en input au reusable workflow.

Comment utiliser un secret GitHub Actions dans une condition if ?

Pas directement : secrets ne peut pas être lu à l'intérieur d'une condition if:. Il faut d'abord affecter le secret à une variable env au niveau du job ou du step, puis tester cette valeur env dans la condition if:. C'est l'un des trois emplacements à risque que le panneau de références met en évidence pour chaque référence secrets.*.

Pourquoi le numéro de version matrix 3.10 devient-il 3.1 ?

YAML lit un 3.10 non entre guillemets comme le nombre 3.1, en perdant silencieusement le zéro final — une particularité du parsing YAML, pas un bug de GitHub Actions. Le générateur de matrice détecte les valeurs qui ressemblent à des numéros de version et les met automatiquement entre guillemets en insérant le strategy.matrix généré.

Un workflow que cet outil juge mal ?

Essayer ce validateur GitHub Actions maintenant

Collez un workflow dans ce validateur GitHub Actions, observez l'arbre job/step et la liste des références se mettre à jour, puis préparez un brouillon de matrix ou de cron au besoin.

Tout reste dans le navigateur — rien n'est envoyé, et aucun workflow n'est jamais déclenché.

Retour à l'outil Voir les outils CI/CD

Toute l'analyse se fait localement dans le navigateur.

validateur GitHub Actionsformatage, validation et navigation dans chaque job