0%
Un premier workflow qui exécute vos tests

Un premier workflow

De l'arborescence du fichier à la lecture d'un journal d'échec.

10-15 min

Le premier workflow d'un projet échoue presque toujours, et presque jamais pour la raison qu'on croit. Le fichier est refusé parce qu'il est dans .github/workflow/ au singulier. La commande npm test répond que le fichier package.json est introuvable, parce que le dépôt n'a jamais été récupéré. Ou tout fonctionne, et vous découvrez que les tests tournent en trente secondes au lieu de trois, parce que rien n'est mis en cache. Ces trois écueils viennent du même point aveugle : un runner est une machine vide, qui ne sait rien de votre projet.

Cette leçon construit un workflow de tests réellement utilisable, une ligne après l'autre, en expliquant pour chacune ce qui casse si on l'omet. Elle se termine sur la lecture d'un journal d'exécution, parce que la compétence qui fait gagner du temps sur la durée n'est pas d'écrire le fichier, c'est de savoir, en trente secondes, si un échec vient de votre code ou de votre configuration.

L'emplacement du fichier

GitHub ne détecte que les fichiers .yml ou .yaml situés directement dans .github/workflows/, à la racine du dépôt.

mon-projet/
├── .github/
│   └── workflows/
│       ├── tests.yml
│       └── publication.yml
├── src/
└── package.json

Commentaires

Les commentaires sont alimentés par GitHub Discussions

Connectez-vous avec GitHub pour participer à la discussion

Lien copié !