Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30

[UncleSam]

@unclesam sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Langsam sollten wir uns wohl mal über das Projekt CHIP unterhalten.

Neu heisst die Plattform nun Matter.

[Jey Cee]

@unclesam sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Weshalb? Wenn ein Adapter zB nur ab Node 14 läuft, ist das der Entscheid des Entwicklers. Klar, das muss richtig in der (io-)package.json stehen, aber das war's schon.

Weil dann vor jedem release gegen die Aktuellen vorgaben getestet wird. Und es ist eine unnötige Arbeit vor jedem release zu prüfen was gerade Aktuell ist und was im Testing hinterlegt ist.
Mit dem "das wars schon" machst du es dir doch etwas zu einfach, Nehmen wir alle "das wars schon" Zusammen, haben wir plötzlich für einen release 30(?) Minuten Zusätzliche Arbeit wenn man immer alles durchgeht.

@unclesam sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Der Adapter Checker überprüft doch nur den Inhalt von GitHub, der führt keine Tests aus.

Das mag richtig sein, er prüft aber auch unnötiger weise ob die package files Korrekt sind. Es wäre Sinnvoller diese Tests schon vorher zu machen. Wenn ich einen Adapter ins Beta/Stable bekommen will wird das erst dort geprüft, was Zusätzliche Arbeit für den review Prozess bedeutet.
Davon abgesehen könnten eigentlich alle Überprüfungen die der Checker macht direkt mit GH Actions ausgeführt werden. Das sparrt einen weiteren Schritt.

@unclesam sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Das scheint mir ein etwas verkehrter Schluss: wenn ich die Standard Tests mit allen Umgebungen (OS und Node Matrix) auf GitHub ausführe, weiss ich ja ganz genau, dass mein Adapter überall dort läuft. Und wenn nicht, kann ich das ja entsprechend in der (io-)package.json eintragen.

Wieder ein Zusätzlicher Schritt den ich extra machen muss. Ich versteh nicht wieso ich das selber machen muss wenn das Testing doch das Ergebnis liefert und auch gleich Eintragen kann.
Deine Annahme impliziert auch das jeder Entwickler das immer macht, das glaube ich aber nicht.
Aber die Eigentliche Idee dahinter ist das Explizit erkennbar ist mit welchen Versionen es auf jeden Fall funktioniert. Jetzt ist es so das man es nie wirklich weis weil das nirgendwo angezeigt wird, bestenfalls steht es in der Readme.
Ist die Information hinterlegt kann man sie abrufen und im Admin anzeigen.

So wie es zum Beispiel die Foren Software macht:

@unclesam sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Ja, kann man. Wobei es mir eigentlich oft reicht, wenn ich von GitHub ein "OK" bekomme (klar, wenn ich Tests schreibe, dann teste ich die auch lokal).

Ganz ehrlich da schau ich nicht immer drauf. Das Ergebnis ist für mich nur von belang wenn es einen Fehler gibt und es sich um ein release handelt, genau dann will ich benachrichtigt werden.

@alcalzone sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Es kommt öfter mal vor, dass ein Adapter nur auf einem OS oder unter einer bestimmten Node-Version nicht funktioniert. Das kannst du offline effektiv fast nicht testen.

Da muss ich dir recht geben.

[AlCalzone]

@jey-cee sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Ich versteh nicht wieso ich das selber machen muss wenn das Testing doch das Ergebnis liefert und auch gleich Eintragen kann.

Aber das Ergebnis reicht eben nicht, weil du es interpretieren musst. @foxriver76 hatte vorhin erst einen Fall, wo in den package Skripten node_modules/.bin/mocha statt nur mocha stand und der Test unter Node 16 fehlgeschlagen ist. Nicht etwa weil es nicht lief, sondern weil das mitgelieferte npm 7 die Binaries woanders ablegt.

Und es ist eine unnötige Arbeit vor jedem release zu prüfen was gerade Aktuell ist und was im Testing hinterlegt ist.

Dann mach's halt nicht vor jedem Release, sondern dann wenn es im Dev-Chat mal wieder heißt: "hey, Node XYZ ist bald LTS" - so ca. jedes 1/2 Jahr.

Davon abgesehen könnten eigentlich alle Überprüfungen die der Checker macht direkt mit GH Actions ausgeführt werden. Das sparrt einen weiteren Schritt.

Stimme ich dir zu - geht grundsätzlich auch. PR welcome: https://github.com/ioBroker/testing/blob/master/src/tests/packageFiles/index.ts

[Garfonso]

@jey-cee said in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Aber die Eigentliche Idee dahinter ist das Explizit erkennbar ist mit welchen Versionen es auf jeden Fall funktioniert.

Wenn jeder Adapter nur mit einer Node Version sicher Funktioniert hat man aber schnell die Situation, dass man bei 3-4 "akzeptablen" Node Versionen vor dem Problem steht, dass man sich entscheiden muss...?? Das macht es doch nicht besser...
Aktuell sehe ich das so, wenn man das Testing per Github Actions mit der Matrix aus Node-Version und OS ok pflegt (wie @AlCalzone sagt, reicht es da zweimal im Jahr reinzugucken, öfter mache ich das auch nicht), dann kann man davon ausgehen, dass alle Adapter auf allen Node-Versionen laufen außer es steht in einer der Config-Dateien ein requirement von einer anderen Version.
Und das musst du dann ja da als Entwickler auch nur eintragen, wenn deine Tests auf Github nicht mehr durchlaufen und da immer nur eine Version schief geht...

Ich muss sagen, dass ich das, insbesondere mit dem relase-script zusammen und automatischen npm build sehr komfortabel finde. Ich mache npm run release -> das kümmert sich um alles und ich bin fertig. Später bekomme ich eine E-mail von NPM, dass ein neues Paket veröffentlicht wurde oder eine E-Mail von Github, dass es Fehler beim Test gab und ich kann ggf. reagieren (PR für stable oder fixen und neu versuchen).

[UncleSam]

@garfonso sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Ich muss sagen, dass ich das, insbesondere mit dem relase-script zusammen und automatischen npm build sehr komfortabel finde. Ich mache npm run release -> das kümmert sich um alles und ich bin fertig. Später bekomme ich eine E-mail von NPM, dass ein neues Paket veröffentlicht wurde oder eine E-Mail von Github, dass es Fehler beim Test gab und ich kann ggf. reagieren (PR für stable oder fixen und neu versuchen).

My words! Geht mir auch so.

Und wartet auf die (über)nächste Version von iobroker.dev... da habe ich noch ein paar Tools in Planung, die einen Release mit dem Release Skript noch einfacher machen - stay tuned!

[andre]

Moin,
da ich nun auch weiß, dass ich heute Abend wohl dabei sein kann, hätte ich nochmal ein Thema zu Docker. Passt vielleicht in das "woran er gerade arbeitet".
Ich habe vor einiger Zeit aus lauter Faulheit und weil der Docker Container immer "unhealthy" wird wenn ich den js-controller update ein (bisher unglaublich simples) maintenance script eingebaut. Würde euch dazu gerne mal die bisherige Funktion zeigen und mir Feedback abholen ob das eine sinnvolle Automatisierung für die Allgemeinheit ist, oder ob es doch besser undocumented bleiben sollte.
Also vielleicht als Unterpunkt zum ersten Punkt...

• Maintenance Script für Docker Container - Ideen und Feedback? (andre)

MfG,
André

[Dutchman]

Link zum Teams Meeting : https://teams.microsoft.com/l/meetup-join/19%3Ameeting_ZjYyY2JiMzktZThhZi00MDlhLTk1ZmItNjg4MDcwZjEyMTU5%40thread.v2/0?context={"Tid"%3A"acd9fe6e-0a90-4965-877c-b73cabe80b83"%2C"Oid"%3A"89f19cbc-f979-40b1-82a8-98df88138249"}

[AlCalzone]

@ldittmar sagte in Meeting für ioBroker Core/Dev/Admin 19.05.21 20:30:

Statistik/Analytik-Plattform

Original-Projekt mit Installationsanleitung:
https://github.com/robertsLando/statistics-server

Mein Fork mit ergänzten Collections:
https://github.com/zwave-js/statistics-server

Screenshots der Oberfläche:

Code zum Reporten von Statistiken:
https://github.com/zwave-js/node-zwave-js/blob/master/packages/zwave-js/src/lib/telemetry/statistics.ts

[David G.]

Hallo,

ich melde mich mal hier im Thread, weil ich absolut nicht weiß, wem ich eine PN schreiben soll zu meinem Anliegen.

Vom Titel des Threads vermute ich, dass hier irgendjemand der richtige Ansprechpartner ist.

Gerne würde ich das "Projekt" ioBroker unterstützen.
Meiner Meinung nach ist es immer gut, wenn man Gabenorienorientiert bzw nach seinen Möglichkeiten helfen kann.

Ich bin der "Junior" in der elterlichen Druckerei mit angeschlossenen Werbeagentur.
Ich bin der Betriebsleiter im Bereich Druck und Produktion.

Deshalb würde ich, wenn Bedarf besteht, gerne mit Druckprodukten jeglicher Art Hilfe anbieten.

Im Moment hab ich keine Ahnung, wo ihr sowas brauchen könntet.
Hoffentlich habt ihr direkt eine gute Idee.

Sollte hier keiner Mitlesen, für den es relevant ist, kann es ja ggf. jmd weiterleiten.

[UncleSam]

@david-g Besten Dank für dein Angebot! Selbstverständlich sind wir immer froh um Unterstützung. Ich denke, in diesem Fall wären @Bluefox und @apollon77 die richtigen Ansprechpartner.