GitHub Actions : linter et corriger vos workflows YAML

Pourquoi contrôler un workflow avant de merger sur main ?

Un fichier .github/workflows/*.yml qui ne parse pas, ou un job sans runs-on, ne se voit souvent qu'après le push : pastille rouge, logs GitHub, revue bloquée. FastMinify n'embarque pas actionlint. Le validateur GitHub Actions fait des contrôles structurels dans le navigateur — on, jobs, steps avec run ou uses — et le formateur GitHub Actions réindente le YAML (convention 2 espaces). Le cluster complet est sur le hub outils CI/CD. Pour automatiser minify JS/CSS dans la pipeline, voir le guide minification CI/CD.

Repérer un YAML invalide, un on/jobs manquant ou un step vide avant le push

Formater l'indentation 2 espaces pour une revue lisible

100 % dans le navigateur — le workflow n'est jamais envoyé

Plafond 512 Kio UTF-8, comme les autres outils DevOps du site

Garder actionlint (expressions ${{ }}) et le pin des actions pour la CI

Anatomie d'un workflow : ce que FastMinify vérifie (et ce qu'il ne vérifie pas)

La forme minimale d'un workflow GitHub Actions

Un workflow est un document YAML unique. GitHub exige un déclencheur on et une map jobs. Chaque job a besoin d'un runner (runs-on), d'un workflow réutilisable (uses), ou d'une liste steps. Chaque step doit définir run ou uses.

Un seul document YAML — les documents multiples (--- répétés) sont rejetés

La racine doit être un mapping, pas un scalaire ni une liste

Job réutilisable : uses sans steps est accepté ; le YAML imbriqué n'est pas inspecté en profondeur

Un jobs vide ou une liste steps vide produit un avertissement, pas forcément une erreur bloquante

Le panneau de résultats compte jobs, steps et déclencheurs on après un parse réussi

Formater, valider, actionlint : trois couches, pas un seul bouton

FastMinify expose deux outils. Ni l'un ni l'autre n'est actionlint. Confondre les trois mène à des workflows « valides » qui cassent quand même en CI.

Avant

name: CI
on: push
jobs:
 build:
  runs-on: ubuntu-latest
  steps:
  - uses: actions/checkout@v4
  - run: npm test

Après

name: CI
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

Formater : round-trip js-yaml, indentation 2 espaces (convention GitHub) — voir format-github-actions

Valider : parse YAML + structure on / jobs / steps — voir validate-github-actions

actionlint : expressions ${{ }}, permissions, IDs, lookup d'actions — à lancer en CI, pas dans FastMinify

Les commentaires YAML sont supprimés au formatage (même limite que beautify-yaml) — gardez une copie si vous en dépendez

Un verdict « structure OK » ne prouve pas que actions/checkout@v4 existe ni que l'expression est sûre

Expressions ${{ }} et injection : hors périmètre navigateur

Interpoler un contexte non fiable (github.event.issue.title, un label de PR) directement dans run: est un classique d'injection de script. FastMinify n'évalue pas les expressions et ne signale pas ce motif.

Passez les valeurs non fiables via env:, pas en interpolation dans le script

Restreignez permissions: au minimum (contents, pull-requests)

Pinnez les SHAs ou tags d'actions plutôt qu'un flottant non revu

actionlint et une revue humaine restent le filet pour ce risque

Le validateur FastMinify accepte un step qui a run ou uses — même si le script est dangereux

Valider puis formater : un workflow concret

Utiliser le validateur GitHub Actions

Ouvrez le validateur GitHub Actions, collez un seul fichier workflow (max 512 Kio) et attendez le debounce (~300 ms). Le panneau affiche un verdict, les issues avec un indice de ligne sur les erreurs de parse, et des compteurs jobs/steps/triggers. Un champ vide reste inactif — pas « invalide ».

Contrôles : on, jobs, runs-on ou uses ou steps, chaque step avec run ou uses

Pas de lookup marketplace, pas d'évaluation ${{ }}, pas de pin d'actions

Jobs réutilisables (uses au niveau job) acceptés sans steps

Tout reste local — pas de compte, pas d'upload vers un serveur FastMinify

Formater le YAML avant la pull request

Le formateur GitHub Actions pretty-print via js-yaml. Collage, upload ou sample : format automatique ; après une édition manuelle, utilisez le bouton Formater (⌘↵). L'indentation UI suit la convention 2 espaces. Ce n'est pas un réécrivain sémantique.

Alignez un gist ou un exemple de docs mal indenté

Les commentaires # disparaissent au round-trip — copiez-les d'abord si besoin

Enchaînez format → validate pour une revue lisible et une structure saine

Pour du YAML hors Actions, utilisez beautify-yaml plutôt que cet outil

Scénario — step sans run ni uses

Un collègue a ajouté - name: empty step sans script. La CI échoue tard, avec un message GitHub peu lisible dans l'overlay de PR.

Étape 1 : coller le workflow dans validate-github-actions

Ouvrez validate-github-actions. Un verdict invalide du type « step needs run or uses » pointe le step vide.

Étape 2 : ajouter run ou uses

Remplacez le step par uses: actions/checkout@v4 ou un run: réel. Recollez jusqu'à ce que le panneau affiche une structure valide.

Étape 3 : formater et ouvrir la PR

Passez le YAML corrigé dans format-github-actions, copiez, commitez. Les reviewers lisent des jobs indentés, pas un blob.

Scénario — workflow collé depuis un ticket, indentation cassée

Un exemple copié depuis la doc GitHub ou un gist arrive avec un mélange d'espaces. Vous ne voyez plus où finit un job.

Étape 1 : formater d'abord si le fichier est illisible

Collez dans format-github-actions. Cette étape ne prouve pas que le workflow est structurellement complet.

Étape 2 : valider le document indenté

Copiez la sortie dans le validateur. Vérifiez on, jobs et que chaque step a une action.

Étape 3 : garder actionlint pour la CI

Une fois la forme OK, le filet expressions / IDs / marketplace reste en pipeline — FastMinify ne le remplace pas.

Garder actionlint (et minify) dans la CI

Exemple de job actionlint — à pinner dans votre dépôt

Le navigateur sert la boucle rapide avant git push. Les équipes gardent actionlint comme gate de merge pour les expressions ${{ }} et les règles que FastMinify n'implémente pas. L'exemple suit le script officiel de téléchargement actionlint : pinnez une version dans votre repo plutôt qu'un main flottant. Pour minifier JS/CSS dans la même pipeline, voir le guide minification CI/CD.

Exemple de base

name: Lint GitHub Actions workflows
on:
  pull_request:
    paths:
      - '.github/workflows/**'
jobs:
  actionlint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check workflow files
        run: |
          bash <(curl https://raw.githubusercontent.com/rhysd/actionlint/main/scripts/download-actionlint.bash)
          ./actionlint -color
        shell: bash

GitLab CI et le reste du hub

Si le dépôt est sur GitLab, les pendants sont format-gitlab-ci et validate-gitlab-ci — même idée (YAML + structure, pas un runner). Dockerfile et Compose restent sur le hub DevOps : linter un Dockerfile, valider Compose et .env.

Conclusion

Collez le workflow, corrigez la structure (on, jobs, steps), reformatez l'indentation, puis poussez. FastMinify fait cette boucle en local, sans envoyer le YAML. Ce n'est pas actionlint : expressions, permissions avancées et existence des actions restent en CI et en revue. Pour du YAML générique, restez sur beautify-yaml ; pour GitLab, sur le même hub CI/CD.

Validez ou formatez un workflow GitHub Actions maintenant

Validez la structure avant chaque PR qui touche .github/workflows

Formatez pour la revue, mais attendez-vous à perdre les commentaires YAML

Ne traitez pas un verdict FastMinify comme un feu vert actionlint

Gardez l'injection ${{ }} et le pin d'actions dans la revue + la CI

Enchaînez validate → format, puis actionlint sur le merge