Testez vos conditions if: et vos déclencheurs avant de pousser.

Il comporte deux onglets. L’évaluateur d’expressions exécute vos expressions ${{ }} contre un contexte fictif éditable (github, env, matrix, steps, needs) en utilisant la sémantique exacte de GitHub Actions — les opérateurs, l’égalité de chaînes == insensible à la casse, les règles de coercition à la manière de JavaScript, et les fonctions documentées comme contains, startsWith, endsWith, format, join, toJSON, fromJSON, success(), failure(), always() et cancelled(). Le simulateur de déclencheurs vous permet de décrire un événement push, pull_request ou tag et affiche un tableau RUN ou SKIPPED par job qui explique exactement quel filtre on: branches, tags, paths ou paths-ignore a décidé du résultat. Ensemble, ils répondent aux questions « ce if: sera-t-il vrai ? » et « ce workflow va-t-il seulement se déclencher ? » avant de pousser.

Presque toujours parce que le if: contient du texte littéral en dehors des ${{ }} — par exemple if: "${{ github.event_name }}" == 'push' ou if: always-deploy. GitHub n’évalue pas toute la ligne comme une seule expression ; les caractères littéraux font de la condition une chaîne non vide, et une chaîne non vide est vraie (truthy), donc l’étape s’exécute à chaque fois. Enveloppez la condition entière dans un seul ${{ }} (par ex. if: ${{ github.event_name == 'push' }}) et l’évaluateur d’expressions signalera le piège (actions/runner#1173) et vous montrera le résultat corrigé, vrai ou faux.

Collez l’expression dans l’onglet de l’évaluateur d’expressions et modifiez le contexte fictif github/env/matrix/steps/needs pour correspondre à l’exécution qui vous intéresse — aucun commit, aucun push, aucune attente d’un runner. Vous obtenez la valeur évaluée instantanément, ainsi qu’un avertissement si la syntaxe se transformait silencieusement en toujours-vrai. C’est le moyen le plus rapide de vérifier une condition if: ou une interpolation ${{ }} avant qu’elle n’atteigne GitHub Actions.

Ce sont des fonctions de contrôle de statut que vous utilisez dans un if:. success() n’est vrai que lorsque chaque étape ou job requis précédent a réussi (c’est la valeur par défaut implicite dès que vous n’écrivez aucun if:), failure() est vrai lorsque l’un d’eux a échoué, cancelled() est vrai lorsque le workflow a été annulé, et always() force l’étape à s’exécuter quel que soit le statut précédent — y compris en cas d’annulation. Le piège est qu’écrire un if: personnalisé supprime la garde implicite success(), donc if: env.DEPLOY == 'true' s’exécutera même après l’échec d’une étape précédente, sauf si vous ajoutez && success(). L’évaluateur vous permet de basculer le statut fictif et de voir chaque fonction se résoudre.

Les causes habituelles sont une ref qui ne correspond pas à votre glob on: branches ou tags, le fichier de workflow qui n’existe pas encore sur la branche cible, ou un filtre paths qui exclut chaque fichier modifié. Une cause subtile : lorsque vous définissez à la fois branches et paths sous le même événement, ils se combinent par ET — l’événement doit correspondre aux deux, pas à l’un ou l’autre. Décrivez votre événement dans le simulateur de déclencheurs et il rejoue les filtres on: et vous indique la raison décisive pour chaque job.

Au sein d’un même événement, branches (ou tags) et paths sont combinés par ET : un push doit être sur une branche correspondante et toucher un chemin correspondant pour que le workflow s’exécute. À l’intérieur d’un seul filtre, les motifs sont combinés par OU — un seul glob de branche ou un seul chemin modifié qui correspond suffit. Le simulateur de déclencheurs rend cela explicite en affichant séparément la décision de branche et la décision de chemin, puis le verdict combiné RUN ou SKIPPED.

* correspond à n’importe quels caractères sauf le séparateur de chemin /, tandis que ** correspond à travers les séparateurs y compris /, donc feature/** correspond à feature/a/b mais feature/* ne correspond qu’à feature/a. Le moteur de glob honore aussi +, ?, la négation !, et l’échappement \ de la même manière que GitHub. Le simulateur de déclencheurs utilise une réimplémentation fidèle de ces règles pour que vous puissiez tester un motif tel que 'release/**' ou '!**/*.md' contre une ref ou une liste de fichiers réelle et voir ce qui correspond.

Dans le simulateur de déclencheurs, vous fournissez le type d’événement, le nom de la ref et la liste des fichiers modifiés ; l’outil évalue alors les filtres on: de chaque job et tout if: au niveau du job contre cet événement simulé, puis affiche une ligne RUN ou SKIPPED avec la raison décisive — « la branche correspondait mais pas le chemin », « pas de filtre paths », « if: évalué à faux », et ainsi de suite. Il reproduit l’ordre de décision de GitHub Actions plutôt que de deviner, de sorte que le verdict correspond à ce que ferait le véritable runner pour cet événement.

actionlint est un linter statique pour la syntaxe des workflows et le typage des expressions, et act exécute réellement vos jobs dans des conteneurs Docker locaux — tous deux sont excellents et valent la peine d’être utilisés. Cet outil ne fait ni l’un ni l’autre : il n’exécute pas vos étapes et ce n’est pas un vérificateur de types. C’est un espace d’essai sémantique qui évalue une seule expression ${{ }} ou simule le filtrage des déclencheurs contre un contexte que vous contrôlez, dans le navigateur, pour que vous puissiez raisonner sur pourquoi un if: est vrai ou pourquoi un workflow s’est déclenché ou non, sans lancer de conteneurs ni pousser de commits.

Tout ce qui dépend de l’état réel du runner. hashFiles() a besoin des fichiers réels sur le disque, donc l’évaluateur le traite comme un espace réservé opaque plutôt que de calculer un véritable hachage ; la charge utile complète du webhook est bien plus volumineuse que le contexte github fictif que nous exposons ; et le contenu en direct des actions, les secrets et les étiquettes de runner ne sont pas résolus. Considérez un résultat propre comme une forte confiance avant le push concernant la logique des expressions et des déclencheurs — et non comme une garantie sur le hachage des fichiers ou la charge utile complète de l’événement.

Non. Les deux onglets s’exécutent à 100 % côté client. Les expressions, le contexte fictif, les filtres de workflow et les charges utiles d’événements que vous saisissez sont évalués à l’intérieur de votre onglet de navigateur — rien n’est envoyé, il n’y a pas de compte, et il n’y a pas d’inscription. Vous pouvez coller en toute sécurité des workflows internes ou propriétaires, y compris des noms de secrets, des étiquettes de runner privées et de vraies listes de branches et de chemins.

Non. Il s’agit d’un outil communautaire indépendant qui n’est ni affilié à GitHub, Inc., ni approuvé ou sponsorisé par celle-ci. « GitHub » et « GitHub Actions » ne sont utilisés ici qu’à titre descriptif, pour identifier le format d’expression et de déclencheur de workflow que l’outil évalue.