Créer un pipeline CI pour Explainer.js

Cette semaine, nous avons créé un pipeline CI pour mon Explainer.js. Comme j'ai mis en place différents scripts au cours des dernières semaines, c'était assez simple.

Configuration de CI dans Explainer.js

La première configuration du pipeline CI consiste à ajouter un fichier YML dans le répertoire .github/workflows. J'ai utilisé la version par défaut du modèle node.js CI de GitHub mais avec quelques modifications. J'ai d'abord fait un brouillon de PR avec les options par défaut. Ensuite, j'ai tiré la branche et fait plusieurs ajustements. J'ai changé le nom, divisé le travail de construction en trois travaux distincts. Construisez pour installer le nœud, puis lint-and-format et enfin testez pour exécuter les tests. J'ai également utilisé le mot-clé "besoins" pour ignorer le travail suivant. Ainsi, si le précédent échoue, le suivant sera ignoré. Ainsi, si la configuration du nœud échoue, il n'exécutera pas de lint-and-format et si lint-and-format échoue, il n'exécutera pas de tests. Ce qui s'est produit plusieurs fois parce que mon index.test.js n'était pas configuré correctement, j'ai donc dû apporter une petite correction en passant la clé test-api via argv pour qu'il s'exécute. Cela fonctionnait bien localement car j'ai déjà configuré un .toml et un .env. La configuration de lint-and-format était assez simple puisque j'exécute le script lorsque j'essaie de valider localement afin qu'il formate automatiquement mes fichiers. J'ai apporté des modifications au fichier YML par défaut en fonction de mes besoins de mon projet. Et ça marche plutôt bien ! Vérifiez-le.

Travailler dans DocBot

J'ai travaillé sur DocBot. Bien que le projet soit en JS, ce projet utilise un framework de test différent appelé vitest qui est compatible avec Jest. Une chose que j'ai immédiatement remarquée à quel point c'était rapide par rapport à une simple plaisanterie. Et la sortie du terminal est super polie. Rendre le travail sur la question très agréable. J'ai travaillé pour rendre la suite de tests file.test.js indépendante du système d'exploitation. Je l'ai exécuté dans mon terminal WSL qui a bien fonctionné mais il n'a pas fonctionné dans cmd.exe. J'ai immédiatement remarqué que la structure du chemin attendu était différente. Quelque chose que j'ai découvert lorsque j'ai fini d'écrire mes tests dans explicator.js la semaine dernière. J'utilise WSL par défaut mais je me souviens que tout le monde ne l'avait pas, alors je l'ai exécuté dans cmd.exe et j'ai eu le même problème pour les tests que j'ai écrits dans FilePathResolver.test.js, j'ai donc dû le résoudre. Ainsi, il est facile de négliger l'exécution du terminal dans différents systèmes d'exploitation lors de l'utilisation du terminal vscode de configuration par défaut. Donc, après quelques essais et erreurs, je l'ai corrigé et j'ai fait mon PR.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!