Un premier workflow
De l'arborescence du fichier à la lecture d'un journal d'échec.
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