Erstellen einer CI-Pipeline für Explainer.js

Diese Woche habe ich eine CI-Pipeline für mein Explainer.js erstellt. Da ich in den letzten Wochen verschiedene Skripte erstellt habe, war es ziemlich einfach.

CI in Explainer.js einrichten

Der erste Schritt zum Einrichten der CI-Pipeline ist das Hinzufügen einer YML-Datei im Verzeichnis .github/workflows. Ich habe die Standardversion der CI-Vorlage „node.js“ von GitHub verwendet, jedoch mit einigen Änderungen. Zuerst habe ich einen PR-Entwurf mit den Standardoptionen erstellt. Dann habe ich den Ast gezogen und mehrere Anpassungen vorgenommen. Ich habe den Namen geändert und den Build-Job in drei separate Jobs aufgeteilt. Erstellen Sie, um den Knoten zu installieren, und führen Sie dann eine Lint- und Formatierung durch und testen Sie schließlich, um die Tests auszuführen. Ich habe auch das Schlüsselwort „Bedarf“ verwendet, um den nächsten Job zu überspringen. Wenn also der vorherige fehlschlägt, wird der nächste übersprungen. Wenn also die Knoteneinrichtung fehlschlägt, wird „lint-and-format“ nicht ausgeführt, und wenn „lint-and-format“ fehlschlägt, werden keine Tests ausgeführt. Was ein paar Mal passiert ist, weil mein index.test.js nicht richtig eingerichtet war, sodass ich eine kleine Korrektur vornehmen musste, indem ich den test-api-key über argv übergeben habe, damit es ausgeführt werden konnte. Es lief lokal einwandfrei, da ich bereits eine .toml- und eine .env-Datei eingerichtet habe. Das Einrichten von „lint-and-format“ war ziemlich einfach, da ich das Skript ausführe, wenn ich versuche, lokal einen Commit durchzuführen, sodass meine Dateien automatisch formatiert werden. Ich habe entsprechend den Anforderungen meines Projekts Änderungen an der Standard-YML-Datei vorgenommen. Und es funktioniert ziemlich gut! Probieren Sie es aus.

Arbeiten in DocBot

Ich habe an DocBot gearbeitet. Obwohl das Projekt in JS ist, verwendet dieses Projekt ein anderes Test-Framework namens vitest, das Jest-kompatibel ist. Eine Sache ist mir sofort aufgefallen, wie schnell es im Vergleich zum bloßen Scherz war. Und der Terminalausgang ist superpoliert. Die Arbeit an diesem Thema macht sehr viel Spaß. Ich habe daran gearbeitet, die Testsuite von file.test.js betriebssystemunabhängig zu machen. Ich habe es in meinem WSL-Terminal ausgeführt, was einwandfrei lief, aber nicht in cmd.exe. Mir fiel sofort auf, dass die erwartete Pfadstruktur anders war. Etwas, auf das ich letzte Woche gestoßen bin, als ich mit dem Schreiben meiner Tests in EXPLAINER.JS fertig war. Ich verwende WSL standardmäßig, aber ich erinnere mich, dass nicht jeder es hat, also habe ich es in cmd.exe ausgeführt und hatte das gleiche Problem für die Tests, die ich in FilePathResolver.test.js geschrieben habe, also musste ich es beheben. Daher kann es leicht übersehen werden, dass das Terminal unter verschiedenen Betriebssystemen ausgeführt wird, wenn das Standard-Setup-Vscode-Terminal verwendet wird. Nach einigem Ausprobieren habe ich das Problem behoben und meine PR erstellt.

Das obige ist der detaillierte Inhalt vonErstellen einer CI-Pipeline für Explainer.js. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!