@VonOx Ich finde, dass die aktuelle Buildzeit der PRs wirklich lang ist (fast 20-25 Minuten), was das Mergen mehrerer PRs sehr lang macht.
Aktuell dauert es, um 3 PRs zu mergen, wenn ich das sauber mache, indem ich jede PR einzeln merge, um einen sauberen Commit zu haben, 1,5 Stunden, egal was der Inhalt der PRs ist und ohne die Reviewzeit mitzuzählen ^^
Daher habe ich recherchiert und einen ersten Optimierungsansatz gefunden: die Aufgaben besser parallelisieren.
Zum Beispiel braucht die Aufgabe « Build Front + Docker Magic » nicht die Aufgabe « Test-Server » (für eine PR, auf Master wollen wir, dass die Tests vor dem Docker-Build durchlaufen, aber hier ist das nicht so relevant), also frage ich mich, ob wir die Abhängigkeit entfernen könnten?
Ja, ich verstehe die Logik, außer dass es am Ende besser ist, alles gleichzeitig zu starten, auf jeden Fall haben wir am Ende den Abschlussbericht.
Wenn man alles parallelisiert, hat man eine Gesamt-Testzeit von 12 Minuten, das ist immer noch viel, aber es ist halb so lang Das macht für mich einen großen Unterschied. 25 Minuten Buildzeit habe ich das Gefühl, total unproduktiv zu sein, ich verbringe meine Zeit damit zu warten ^^
Zur Info, ich habe die Abhängigkeiten aktualisiert (hauptsächlich Backend, etwas Frontend, aber solange wir keine Tests haben, ist es schwierig) und auf GitHub Actions einen Sicherheitsaudit-Schritt für die Abhängigkeiten hinzugefügt.
Für Cypress denke ich, dass wir eine gute Arbeitsbasis haben, die Anmeldung und die Bluetooth-Seite (echtes Testen + Mocks) sind getestet.
Eine Frage beschäftigt mich: Wie können wir diese Tests in den PRs am Leben erhalten?
Ich muss also prüfen, ob die Testabdeckung mit Cypress erfolgen kann.
Oh jeez, das wird kompliziert, das von Cypress verwendete Code-Coverage-Plugin basiert auf einer Babel 7.x-Version, aber preact-cli 2.x erzwingt die Babel-Version 6.x… ich fange an zu schwitzen…
Um dieses Problem zu lösen, habe ich eine „vorübergehende und schnelle“ Migration von preact-cli auf v3 durchgeführt, und jetzt habe ich einen schönen Bericht
Ja, ich bin einverstanden, dass wir die Aufgaben aufteilen.
Für den Teil mit den Cypress-Tests werde ich allein ewig brauchen. Ich frage mich, ob nicht jeder Entwickler das Thema in die Hand nehmen sollte, um sich „weiterzubilden“ und zumindest seine eigenen Dienste zu testen.
Ansonsten wäre es gut, parallel mit der Migration zu Preact zu beginnen und die kritischen Punkte zu notieren, um sicherzustellen, dass wir sie mit Cypress abdecken.
@contributors Für den Fall, dass ihr es noch nicht gesehen habt, arbeitet @AlexTrovato an der Hinzufügung von Frontend-Tests, die uns dabei helfen werden, Frontend-Regressionen besser zu überwachen. Dafür brauchen wir die Hilfe von euch allen, um jeden Service zu testen
et ich denke, man sollte nach und nach in diesen Zweig mergen.
Für jeden getesteten Dienst einen PR erstellen, nicht in Richtung master, sondern in Richtung dieses Zweigs (falls möglich) und nach und nach mergen.
Ich stehe natürlich für Fragen oder Blockaden zur Verfügung, die bereits vorhandenen Beispiele sollten ausreichen, um die Testbatterie zu vervollständigen, aber es ist sehr wahrscheinlich, dass neue, nicht „bedachte“ Fälle auftreten.
Ich denke zum Beispiel an WebSocket, das ich nicht untersucht habe.
Auf meiner Seite behalte ich meinen Zweig « migration preact 3 temporaire » mit Abdeckung, ich könnte die Abdeckung lokal ausführen, um den Beitragenden zu signalisieren, wenn ein « großer » Teil fehlt.
Wir werden die Abdeckung verfeinern / ergänzen, sobald die Migration validiert ist, denn in meinem temporären Migrationszweig sind viele Funktionen außer Betrieb.
@pierre-gilles ich weiß, dass deine Zeit kostbar ist, also ich würde gerne den « core »-Teil zusätzlich zu meinen Diensten übernehmen, aber ich werde wahrscheinlich nicht in der Lage sein, den Gateway-Teil abzudecken.
Wenn du daran interessiert bist, dich « auszubilden », können wir teilen.
Nur eine zusätzliche Information.
Für jeden „neuen“ Test muss ein JWT-Token über /login generiert werden, und man stößt schnell auf diesen Fehler „Status: 429 - Zu viele Anfragen“.
Möglicherweise muss eine Konfiguration hinzugefügt werden, um diese Prüfung auf Serverseite zu deaktivieren.
Dieses Problem tritt beim Erstellen der Tests auf, bei jedem neuen Test, jedem neuen Lauf, startet man von vorne (wenn ALLE Tests ausgeführt werden, wird das beim ersten Mal generierte Token während des gesamten Vorgangs beibehalten).
Das ist eher lästig.
Warum holst du dir nicht einfach ein JWT beim Starten der Tests (so eine Art before() wie bei mocha, keine Ahnung, ob das existiert?)
Das erscheint mir schwer, bei jedem Test ein Login durchzuführen!
Ich denke, es wäre gut, wenn ich mich auch weiterbilde! Ich würde dann unterstützen, sobald ich die aktuellen Themen (zigbee2mqtt und Co.) abgeschlossen habe.
@pierre-gilles wenn du die Tests entwickelst und deinen neuen Test speicherst, wird Cypress neu geladen (wie der Frontend mit nodemon) und startet von vorne.
Im Fall, dass du alle Tests auf einmal startest, wird dieses Token tatsächlich in der Umgebungsvariable von Cypress gespeichert,
aber es ist wirklich während der Testentwicklungsphase, in der du « Schritt für Schritt » vorgehst, dass das Problem auftritt, denn es ist sehr schwierig, einen guten « grafischen » Test beim ersten Mal zu schreiben, und selbst wenn das der Fall ist, muss man jeden Test nach dem Schreiben testen können, also die Cypress-Umgebung aktualisieren, also ein neues Token generieren.
Okay, nachdem ich den ganzen Vormittag damit gespielt habe, scheint es kein echtes Problem zu sein, sondern eher auf einen Bug in den „spezial“ Befehlen cypress-gladys (helpers) zurückzuführen zu sein, die ich eingerichtet hatte, um den Token zu verwalten
Dadurch konnte ich die WebSocket (zum Erzwingen/Simulieren eines Ereignisses) verwenden.
Weitere Info: Nach der Überprüfung der npm-Abhängigkeitslücken schlägt der Build aufgrund von sequelize-cli und nyc fehl: https://www.npmjs.com/advisories/1654.
Das macht für mich einen großen Unterschied. 25 Minuten Buildzeit habe ich das Gefühl, total unproduktiv zu sein, ich verbringe meine Zeit damit zu warten ^^
