Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[OliverIO]

Hallo,

ich habe gerade die Tests über appveyor und travis nochmal neu angestossen.
Appveyor ist alles grün
Bei Travis sind die Builds für Windos mit node 10 und 12 fehlgeschlagen
Fehlermeldung lautet
Error: Cannot find module 'C:\Users\travis\AppData\Local\Temp\test-iobroker.squeezeboxrpc\iobroker-data\iobroker.json'
Link zu den Buildlogs ist

https://travis-ci.org/oweitman/ioBroker.squeezeboxrpc
https://ci.appveyor.com/project/oweitman/iobroker-squeezeboxrpc

Aus meiner Sicht kann ich da nichts machen, da scheint ein Problem bei Travis zu liegen im Aufbau der Umgebung. Hat da jemand andere Erkenntnisse?

[OliverIO]

Es wäre schön, wenn jemand mit Travis-Kenntnissen in meine Buildlogs reinschaut.
Es sind 2 Build-Variationen schiefgegangen Win+Node10 sowie Win+Node12.
Alle anderen Kombinationen aus Node 8,10,12 mit Mac und Linux sind grün.
Ich kann mir den Fehler nicht wirklich erklären.
Ich habe heute auch nochmal die devDependencies aktualisiert, aber gleiches Ergebnis.
Vielen Dank

[AlCalzone]

@OliverIO

1. Passe bitte deine .travis.yml wie folgt an:
   https://github.com/ioBroker/ioBroker.template/blob/f506a2a84b81fe5e701b941725c20dc9f694ac76/JavaScript/.travis.yml#L30 (die Zeile mit export einfügen, dann sieht man mehr).
2. Manchmal schlagen die Builds aus unerfindlichen Gründen fehl (insbesondere Windows). Einfach mal den jeweiligen Job neu starten.

Edit: Alternativ habe ich im neuesten Template das CI-Testing von Travis+Appveyor auf Github umgestellt. Aus meiner Erfahrung ist das deutlich schneller (meine Builds sind in Summe unter 10 Minuten) und weniger anfällig für zufällige Fehler. Das kannst du auch mal ausprobieren.
--> Diese Datei hinzufügen: https://github.com/ioBroker/ioBroker.template/commit/e9d9312f2fe3abc916e029d0f68968b0f301e3ff#diff-7b34d00ec4f2cbcc568a4cf8b6ea3fe1R1
--> .travis.yml und appveyor.yml löschen.

[OliverIO]

@AlCalzone Danke für den Hinweis.
Habe .travis.yml erweitert und neu laufen lassen:
https://travis-ci.org/oweitman/ioBroker.squeezeboxrpc/builds/618617084
Leider sind dadurch keine weiteren Hinweise im Log enthalten.

Als nächste werde ich die veralteten Dependencies reparieren, die in einem von mir verwendeten Paket https://github.com/pssc/squeezenode
enthalten sind. Evtl gibt es hier mit Node10 und 12 bereits inkompatibilitäten, die es allerdings vor einem halben Jahr noch nicht gab.

Wie gehe ich den da bei mir auf der Festplatte um. Meine Idee war:

1. im github das Paket pssc/squeezenode forken
2. und dann bei iobroker.squeezeboxrpc als dependency im Paket anpassen
3. alle Versionsnummern in meinem geforkten squeezenode anpassen
   4 auf github pushen (leider gibt es bei squeezenode keine gekapselten Tests, nur demos)
   5 mein iobroker.squeezeboxrpc updaten
   6 und dann neu testen

[AlCalzone]

@OliverIO Ich glaube gerade nicht, dass es an deinem Adapter hängt.
Die Integration Tests brechen während der Installation von JS-Controller ab.

[OliverIO]

@AlCalzone so auch die dependencies sind nun aktualisiert und damit die vulnerabilities auf 1 low gesunken.
Test weiterhin mit dem gleichen Fehler.
Ja, soweit ich das sehe, liegt es daran, das für den jeweiligen Test die Testdaten vorkopiert werden.
Dabei geht wohl was schief und die

C:\Users\travis\AppData\Local\Temp\test-iobroker.squeezeboxrpc\iobroker-data\iobroker.json

fehlt dann. Was mich an dem Pfad etwas wundert, ist das iobroker-data innerhalb des adapterpfads sich befindet oder ist das eine buildbesonderheit, das sich im pfad der ganze iobroker befindet? dann passt es wieder. Lustig ist halt, das es bei allen anderen Builds (sogar auch unter Windows bei 8 immer klappt.
Ich werde daher travis erst einmal heraus nehmen, sonst verhunzt es mir die schöne anzeige bei github/Readme :)

Danke für deine Mühe

[AlCalzone]

@OliverIO Das Verzeichnis ist ein temporäres Verzeichnis, damit du auch auf lokalen PCs testen kannst, ohne bestehende Installationen zu beeinträchtigen.
Das Problem scheint zu sein, dass JS-Controller bei der Installation denkt, dass er schon installiert ist und daher setup first nicht aufruft.

Lösche bitte mal den Travis-Cache:

dann

dann Build neu starten. Bisher waren alle unerklärlichen Fehler bei mir durch diesen Cache verursacht. Kannst du auch in .travis.yml deaktivieren.

[OliverIO]

@AlCalzone hab ich nun gemacht, leider keine Veränderung zu den Vorgängerbuilds.