Bessere Kontrolle von sources-dist(-stable) dank jsDelivr?

[UncleSam]

Vor kurzem habe ich etwas ganz böses gemacht:

Spoiler

meine neue Version eines Adapters wollte nicht durch den Adapter-Tester, also habe ich auf meinem GitHub master Branch die Anpassungen gemacht - aber kein neues Release. Ging alles wunderbar und niemand hat sich beklagt - insbesondere der nette Adapter-Tester nicht

Das hat mich zum Denken angeregt und ich habe hier einige Vorschläge, die uns die Arbeit erleichtern und solche "bösen" Taten erschweren.

Grundlage meiner Ideen ist, dass wir uns nicht auf den Inhalt auf GitHub verlassen sollten, sondern direkt auf den Inhalt des freigegebenen NPM Pakets.

Lösung dafür bietet jsDelvir, denn dort kann man eine URL erstellen und ganz einfach (ohne Konfiguration) Dateien aus einem NPM Paket herunterladen. Mehr Infos unter: https://www.jsdelivr.com/

Nun zum Titel des Themas: aktuell schreiben wir in sources-dist.json folgendes pro Adapter:

  "loxone": {
    "meta": "https://raw.githubusercontent.com/UncleSamSwiss/ioBroker.loxone/master/io-package.json",
    "icon": "https://raw.githubusercontent.com/UncleSamSwiss/ioBroker.loxone/master/admin/loxone.png",
    "type": "iot-systems"
  },

Das wäre alles überflüssig mit jsDeliver (es genügt den Namen des Adapters anzugeben, denn die Informationen können wie folgt geholt werden:

• meta: https://cdn.jsdelivr.net/npm/iobroker.<adapter-name>/io-package.json also: https://cdn.jsdelivr.net/npm/iobroker.loxone/io-package.json
• icon: aus dem obigen "meta" holt man sich (bei jedem neuen Release) das Icon, das IMHO nur noch den relativen Pfad haben sollte: "admin/loxone.png" daraus wird https://cdn.jsdelivr.net/npm/iobroker.<adapter-name>/<image-pfad> also: https://cdn.jsdelivr.net/npm/iobroker.loxone/admin/loxone.png
• type: gleich wie "icon" direkt aus dem io-package.json

Dasselbe gilt für sources-dist-stable.json: hier können wir nur Adapter-Name und Version angeben:

"loxone": "2.0.0",

• meta: https://cdn.jsdelivr.net/npm/iobroker.<adapter-name>@<adapter-version>/io-package.json also: https://cdn.jsdelivr.net/npm/iobroker.loxone@2.0.0/io-package.json
• icon: aus dem obigen "meta" wird https://cdn.jsdelivr.net/npm/iobroker.<adapter-name>@<adapter-version>/<image-pfad> also: https://cdn.jsdelivr.net/npm/iobroker.loxone@2.0.0/admin/loxone.png
• type: gleich wie "icon" direkt aus dem io-package.json

Dies hat den grossen Vorteil, dass alle Daten nur aus einem NPM Release kommen und nicht vom (eventuellen Gebastel in) GitHub "master." Ein PR auf ioBroker.repositories ist damit immer noch nötig um eine neue Version ins Stable zu bringen, aber es ist nur noch genau die Versionsnummer zu aktualisieren. Server-seitig kann dann immer noch das alte Format zur Verfügung gestellt werden (insbesondere damit nicht jede ioBroker-Installation auf alle io-package.json zugreifen muss, nur um das Icon und den Typ zu finden.

Und zu guter Letzt: der Adapter-Checker sollte die Option erhalten, entweder GitHub zu testen (für uns Entwickler - und zwar bitte auch mit der Option, einen Branch zu testen) oder eben eine freigegebene Version auf NPM (für den GitHub Bot, der den Adapter beim PR in ioBroker.repositories überprüft).

Ich bin gespannt auf euer Feedback, insbesondere von @Bluefox, @apollon77, @ldittmar, @Jey-Cee und weiteren Core Entwicklern.

[AlCalzone]

@UncleSam sagte in Bessere Kontrolle von sources-dist(-stable) dank jsDelivr?:

Das hat mich zum Denken angeregt und ich habe hier einige Vorschläge, die uns die Arbeit erleichtern und solche "bösen" Taten erschweren.
Grundlage meiner Ideen ist, dass wir uns nicht auf den Inhalt auf GitHub verlassen sollten, sondern direkt auf den Inhalt des freigegebenen NPM Pakets.

Ich hab das Problem noch nicht ganz verstanden, kannst du das bitte nochmal ausführen? Zugegebenermaßen weiß ich aber auch nicht, was mit der meta-Angabe überhaupt gemacht wird.

[UncleSam]

@AlCalzone sagte in Bessere Kontrolle von sources-dist(-stable) dank jsDelivr?:

Ich hab das Problem noch nicht ganz verstanden, kannst du das bitte nochmal ausführen?

Aktuell verwenden wir überall in Admin die Daten von GitHub "master" des jeweiligen Adapters. Es wird aber nirgends sichergestellt, dass das auch der neusten (freigegebenen) Version des Adapters entspricht. Wenn ich z.B. das Icon ändere, dann wird das auf allen ioBroker-Installationen angezeigt, sobald ich die Änderung auf "master" bringe (push, PR oder merge), nicht erst wenn ich die neue Version des Adapters veröffentliche.

[AlCalzone]

@UncleSam Ok jetzt hats Klick gemacht.

Alternativ könnte man aber auch bei Github bleiben. Voraussetzung ist ein korrektes Tag wie es z.B. durchs Release-Skript gesetzt wird. Dann geht auch so ein Link:
https://raw.githubusercontent.com/AlCalzone/ioBroker.zwave2/v1.5.0/io-package.json

[UncleSam]

@AlCalzone Richtig. Wie du aber sagst, benötigt das eine Veränderung des Release-Prozesses durch den Adapter-Entwickler (die übrigens sehr zu empfehlen wäre). Mein Vorschlag würde mit dem heutigen Prozess funktionieren und hätte (ausser der Änderung in ioBroker.repository) keine Auswirkung auf Adapter-Entwickler.

[Jey Cee]

@UncleSam sagte in Bessere Kontrolle von sources-dist(-stable) dank jsDelivr?:

@AlCalzone sagte in Bessere Kontrolle von sources-dist(-stable) dank jsDelivr?:

Ich hab das Problem noch nicht ganz verstanden, kannst du das bitte nochmal ausführen?

Aktuell verwenden wir überall in Admin die Daten von GitHub "master" des jeweiligen Adapters. Es wird aber nirgends sichergestellt, dass das auch der neusten (freigegebenen) Version des Adapters entspricht. Wenn ich z.B. das Icon ändere, dann wird das auf allen ioBroker-Installationen angezeigt, sobald ich die Änderung auf "master" bringe (push, PR oder merge), nicht erst wenn ich die neue Version des Adapters veröffentliche.

Genau das gleiche Thema hatte ich mit der Readme eines Adapters, die war neuer als der Adapter im Stable. Die wird aber im Admin von Github geholt nicht aus dem npm Paket, das hat etwas Verwirrung verursacht.

[apollon77]

Und man muss nichts dafür tun das die files da verfügbar sind?

Am Ende könnte es helfen die aktuellen checker false positive errors weil zu viele GitHub requests vom checker gemacht werden aufzulösen.

Und ja so ist es besser weil wirklich die relevanten files gecheckt werden und bf könnte sich sparen für Repo Bau alle Adapter von npm zu ziehen.

Find ich cool und ja darüber wäre auch das Thema „Admin adapter icons hängen von GitHub ab“ gelöst - ok hängt dann von dem Service ab

Readme ist so ne Sache. Ich mochte es das man die Doku ohne ne neue Adapter Version erweitern kann. Und nur wegen Doku ne neue Version zu publishen fände ich Overkill. Hier also lieber als dev aufpassen.

Meine ganz spontane Meinung dazu.

Ingo

[UncleSam]

@apollon77 sagte in Bessere Kontrolle von sources-dist(-stable) dank jsDelivr?:

Und man muss nichts dafür tun das die files da verfügbar sind?

Jap, kannst es mit irgendeinem Adapter versuchen, das "funktioniert einfach"

[AlCalzone]

Gut das schließt sich ja beides nicht aus. Beim Updaten des Repos könnte dann sichergestellt werden, dass entweder jsDelivr, unpkg (selbes Prinzip) oder zur Not halt ein getaggter Pfad von Github eingetragen ist.

[apollon77]

@AlCalzone man müsste mal versuchen ob’s jetzt schon tut. Also mal einen Pr gegen Repo mit einer der anderen URLs. Ggf mir hard coded Version aber ist ja erstmal egal.