Adapter aus github (versionsnummer)
-
Hallo.
Ich habe einige Adapter aus github installiert. Da ändert sich ja die Releasenummer ohne dass man das direkt in ioB mitbekommt. Gibts evtl. eine möglichkeit das via Script abzufragen welche aus github sind und obendrauf ggf. sogar die Versionsnummer dort abzufragen und zu benachrichtigen wenn es eine neuere gibt?Grüße,
Toby -
cd /opt/iobroker/ && npm ls | grep githubFehlt nur der Check auf ein neues Commit, wobei das auch wenig hilfreich ist, bei aktiver Entwicklung kann sich das binnen Minuten ändern.
-
@thomas-braun sagte in Adapter aus github (versionsnummer):
bei aktiver Entwicklung kann sich das binnen Minuten ändern.
Genau, wie Fehlerbilder und Stabilität...
Wenn man sich direkt bei GitHub bedient, ist das ein Risiko
-
@thomas-braun sagte in Adapter aus github (versionsnummer):
Fehlt nur der Check auf ein neues Commit, wobei das auch wenig hilfreich ist, bei aktiver Entwicklung kann sich das binnen Minuten ändern.
Ja das ist mir bewusst. Auch das Thema fehler. Will kein automatisches Update anstupsen. Es ging nur darum dass ich es nicht total vergesse irgendwann
-
@accessburn sagte in Adapter aus github (versionsnummer):
Es ging nur darum dass ich es nicht total vergesse
Ironie Kannst du ja nicht vergessen, weil GitHub nur für ganz akutes Testing verwendet wird und man das dann schleunigst wieder auf eine released version umbaut, wenn man getestet hat...
-
@thomas-braun sagte in Adapter aus github (versionsnummer):
@accessburn sagte in Adapter aus github (versionsnummer):
Es ging nur darum dass ich es nicht total vergesse
Ironie Kannst du ja nicht vergessen, weil GitHub nur für ganz akutes Testing verwendet wird und man das dann schleunigst wieder auf eine released version umbaut, wenn man getestet hat...
Ich hab zumindest einen Adapter seit 3?4? keine Ahnung Jahren installiert den es nicht im Repo gibt. Rademacher Bridge und der dev hat auch nicht wirklich Interesse daran ihn ins Repo zu bringen.
@accessburn
Bei Testversion/Repoversionen gibt es afaik keine Möglichkeit zu ermitteln von wo der installiert wurde und die Versionsnummer bleibt meinst die alte bis zum nächsten Betarelease.Man kann jedoch ermitteln welcher Adapter im Repo ist und welcher nicht. Nachguck obs eine neue Version gibt, ist aber da eher mau - nicht im Repo heißt automatisch es ist kein Verlass darauf das es Versionnummer dort gibt wo sie sein sollen. Ganz davon abgesehen, dass der dev, die dann auch erhöhen müsste
-
Bei Testversion/Repoversionen gibt es afaik keine Möglichkeit zu ermitteln von wo der installiert wurde und die Versionsnummer bleibt meinst die alte bis zum nächsten Betarelease.
Du siehst von wo der Adapter installiert wurde im Tooltip
Von direkten Installation von GitHub - insbesondere auf produktiven Systemen - wird explizit abgeraten.
GitHub Versionen können sich jederzeit (auch kurzfristig) ändern und durchaus auch in sich inkonsistent und fehlerhaft sein. Versionsangaben von GitHub Installationen sind Schall und Rauch da die Versionsnummer zumindest bei Verwendung der standardmäßigen Umgebung erst im Zuge der Releaseerstellung geändert wird.
Auf explizite Aufforderung durch den Entwickler kann eine GitHub Installation zur Fehlereingrenzung oder zum Test neuer Funktionalität - unter Inkaufnahme des erhöhten Risikos - natürlich erfolgen.
Adapter die nur via GitHub oder npm (also NICHT aus einem der beiden Repositories) installierbar sind sind mit erhöhter Vorsicht zu betrachten. Hier sollte der Entwickler drum ersucht werden eine Aufnahme in die Repositories zu veranlassen indem z.B. ein Issue im Adapterrepository erstellt wird.
Und falls es irgendwie unklar ist:
ioBroker unterstützt folgende Arten von Installation:
-
aus dem STABLE Repository
Das sind Adapter Releases die keine groben Fehler aufweisen (sollten). Natürlich kann es auch dort Fehler geben, die Behebung davon obliegt dem jeweiligen Dev und kann ggF auch dauern.
-
aus dem LATEST Repository
Das sind Adapter Releases die neu erstellt wurden und nur rudimentär getestet sind - oft auch als BETA Releases bezeichnet. Releases aus dem LATEST sind primär für unsere zahlreichen freiwilligen Tester gedacht. BETA / LATEST Releases können durchaus Fehler aufweisen - auch wenn ich davon ausgehe dass jeder aintainer dies zu vermeiden versucht. Vom Einsatz auf produktiven Systemen wird abgeraten außer man braucht irgenein neues Feature (z.B. neues Gerät) unbedingt. Hier muss dann jeder Entscheiden was ihm wichtig ist.
-
direkt von GITHUB
Von Installationen direkt aus Giuthub wird definitiv abgeraten außer auf Anweisung des Maintainers und für den Fall dass man gemeinsam mit diesem etwas testen will. Details siehe oben.
-
direkt von npm
Diese Installation kann erforderlich sein, wenn man eine bestimmte Version installieren möchte / muss. Im Normalfall sollte man direkte npm Installationen ebenso meiden wie direkte GitHub Installationen - ausgenommen um z.B. zu einer bekannten Version downzugraden - obwohl hier wenigstens ein definierter Stand garantiert ist.
Adapter die NUR via npm und/oder nur via GitHub installierbar sind sollte man meiden - diese wurden nicht mal einem rudimentären Review unterzogen und sollten mit dem Attribut "vollständig auf eigenes Risiko verwenden" installiert werden. Hier empfiehlt es sich den Developer zu ersuchen eine Aufnahme in die Repos zu veranlassen. Wenn dieser darauf nicht reagiert sollte man von einer eher kurzen und unklaren Lebensdauer des Adapters ausgehen. Support meiner-/unsererseits für solche Adapter ist mit sicherheit minimalistisch.
-
-
@ticaki said in Adapter aus github (versionsnummer):
Ich hab zumindest einen Adapter seit 3?4? keine Ahnung Jahren installiert den es nicht im Repo gibt. Rademacher Bridge und der dev hat auch nicht wirklich Interesse daran ihn ins Repo zu bringen.
Dann überlege den Adapter zu forken und ihn ggF unter neuem Namen selbst in die Repos aufnehmen zu lassen.
Jedenfalls gilt: Nicht heulen wenn bei einem Update von core Komponenten dann auf einmal nix mehr geht ...*
-
@mcm1957 sagte in Adapter aus github (versionsnummer):
Nicht heulen wenn bei einem Update von core Komponenten dann auf einmal nix mehr geht ...
Das liest sich wie "Sie verlassen das Krankenhaus auf eigene Gefahr"... Den auch bleiben würde man auf eigene Gefahr. Wenn ein Adapter im Repo nicht mehr geht, hilft mir heulen auch nicht weiter
-
@ticaki said in Adapter aus github (versionsnummer):
@mcm1957 sagte in Adapter aus github (versionsnummer):
Nicht heulen wenn bei einem Update von core Komponenten dann auf einmal nix mehr geht ...
Das liest sich wie "Sie verlassen das Krankenhaus auf eigene Gefahr"... Den auch bleiben würde man auf eigene Gefahr. Wenn ein Adapter im Repo nicht mehr geht, hilft mir heulen auch nicht weiter
Die Wahrscheinlichkeit dass dies Eintritt ist wesentlich geringer da bei inkompatiblen Änderungen spätestens im Rahmen des Betatests Lösungen gesucht werden. So wurden z.B. für Adapter die bei Einführung von js-controller 6 eine veraltete adapter-core Version einsetzten ein Workaround umgesetzt. Im Notfall können Adapter die im Repository eingetragen sind und bei denen der jeweiligen Dev nicht (mehr) erreichbar ist auch vom core Team angepasst werden.
Bei GitHub Only Adaptern wird zu 99% nur auf den jeweiligen Entwickler des Adapters verwiesen und darauf dass sich der User wohl bewusst sein sollte, dass er einen Adapter benutzt der nicht in den Repositories enthalten ist, nie reviewed wurde und keine regelmäßigen Checks durchläuft.
Kurz:
Ja ioBroker ist ein offenes System - jeder kann auch jeder Quelle installieren die er findet. Aber von der Installation von Adaptern die nicht in den Repositories gelistet sind wird explizit abgeraten. -
Hellooo,
im Prinzip hast du ja recht...es kommt immer drauf an, wie ich mit dem System umgehe, welche Kenntnisse ich vom ganzen Umfeld und der etwas tieferen Materie habe... und welche Funktionen gebraucht werden...Wenn ich auf Stable fahren würde, kann ich von 86 Adaptern nur ca. 46 benutzen, da die anderen in der letzten Stable-Release nicht mehr funktionieren oder fehler aufweisen...
Um alles auf Stable zu halten, braucht man viel viel viel mehr Dev's und vor allem ein Plan.. .. und auch welche, die sich dann dran halten..
Du machst ja sehr viel, aber mit gefuehlt 5 Mann kann man das nicht stemmen.. von daher bleibt es nicht aus, von Git latest zu ziehen..Ich bin seit 9 Jahren bei iobroker und das Ding ist explodiert.. kann alles aber vieles nur beta/lastest weil einfach die Devs gegangen sind und diejenigen, die beständig arbeiten, einfach es nicht schaffen können..
Die Entwicklung von den Systemen und Nodejs geht immer weiter und alleine alles auf die aktuelle Nodejs zu ziehen, braucht schon jede Menge ressourcen..Von daher, um beim Topic zu bleiben, kann ich Toby verstehen, wenn er da einen Überblick haben möchte..
Versionsnummern baut man eigentlich erst dann, wenn man sicher ist, dass das ganze einigermassen funktioniert, alles dazwischen sind Testversionen, an denen noch entwickelt wird.. da muss man nicht jedesmal eine neue Version erstellen, sonst waeren wir bei Admin Version 2349342 oder so
Ich schau immer nach dem letzten Änderungsdatum, schau mir die Aenderungen an im Code, und im Changelog! und wenn ich der Meinung bin, ein Test! ist es Wert, dann backup machen und die Version mal installiert. Entweder es geht oder nicht, dann halt wieder rollback.. (und genau der Vorgang muss sichergestellt sein)
Das beste Backup nutzt nix, wenn das Restore nicht geht..! (also auch ein Backup von redis machen)Ich hoffe, das war jetzt nicht zu negativ, sondern als gut gemeinte Erkenntnis gedacht
-
@neuschwansteini said in Adapter aus github (versionsnummer):
im Prinzip hast du ja recht...es kommt immer drauf an, wie ich mit dem System umgehe, welche Kenntnisse ich vom ganzen Umfeld und der etwas tieferen Materie habe... und welche Funktionen gebraucht werden...
Wie geschrieben - ioBroker ist ein offenes System und wenn du weißt was du tust dann kannst und darfst du das natürlich tun. No problem.
Wenn ich auf Stable fahren würde, kann ich von 86 Adaptern nur ca. 46 benutzen, da die anderen in der letzten Stable-Release nicht mehr funktionieren oder fehler aufweisen...
Das sollte definitiv nicht so sein. Wenn ein Adapter in Stable nicht mehr funktioniert (!) - und nicht nur ein neues Feature nicht mehr unterstützt - dann gib gerne Bescheid. Entweder schreib mich im Forum an oder noch besser erstell ein Issue beim Adapter in dem du reklamierst dass die Stable Version nicht funktioniert und der Fix im Beta ok wäre. Der Dev braiucht vielleich nur eine Erinerung. Bitte mention mich in solchen Issues - ich schau dass ich das im Auge behalte und den Dev ggF nochmal direkt anspreche. Im Notfall (wenn ein Adapter wirklich nicht mehr in der Stable Release funktioniert - fliegt er auch aus dem Stable Repository raus.
Um alles auf Stable zu halten, braucht man viel viel viel mehr Dev's und vor allem ein Plan.. .. und auch welche, die sich dann dran halten..
Du machst ja sehr viel, aber mit gefuehlt 5 Mann kann man das nicht stemmen.. von daher bleibt es nicht aus, von Git latest zu ziehen..Das kann ich absolut nicht nachvollziehen. Der Erstellen einer Release ist aber geringste Aufwand. Wenn jemand schon auf Github einen Fixe / Erweiterung erstellt hat dann ist das Erstellen einer Release normalerweise ein Aufruf eines Scripts - der Rest geht automatisch bis incl. Veröffentlichung im Latest. Und das Veröffentlichen auf Stable ist für den Dev ein einfacher Klick auf www.iobroker.dev. Ergo die BEHEBUNG von Fehlern scheitert bzw. klemmt oft an der Manpower - für das fehlende Erstellen einer Release oder der Veröffentlichen ist das aber absolut kein Grund. Und damit m.E. auch kein Grund direkt von Github zu installieren.
Ich bin seit 9 Jahren bei iobroker und das Ding ist explodiert.. kann alles aber vieles nur beta/lastest weil einfach die Devs gegangen sind und diejenigen, die beständig arbeiten, einfach es nicht schaffen können..
Bitte um Beispiele. Ja Devs kommen und gehen. Aber das erklärt nur, dass Fehler nicht behoben werden. Nicht dass eine möglicherweise besserer Github Stand nicht in eine Release einfließt.
Die Entwicklung von den Systemen und Nodejs geht immer weiter und alleine alles auf die aktuelle Nodejs zu ziehen, braucht schon jede Menge ressourcen..
Aktualisierungen von Node sind eigentlich kein Grund für Anpassungsaufwand. Primär ändern Hersteller ihre APIs - insbesondere wenn diese nie dokumentiert wurden sondern reverse engeneered wurden macht das viel Aufwand.
Von daher, um beim Topic zu bleiben, kann ich Toby verstehen, wenn er da einen Überblick haben möchte..
Wer GitHub verwendet muss sich auch auf Github und / oder beim jeweiligen Dev direkt informieren. Für erfahrene Entwickler sollte das kein Problem sein, für User die ioBroker einfach nur verwenden wollen sollte eine GitHub Installation tabu sein.
Ich schau immer nach dem letzten Änderungsdatum, schau mir die Aenderungen an im Code, und im Changelog! und wenn ich der Meinung bin, ein Test! ist es Wert, dann backup machen und die Version mal installiert. Entweder es geht oder nicht, dann halt wieder rollback.. (und genau der Vorgang muss sichergestellt sein)
Der Ablauf ist für einen erfahrenen User / Dev gut. Ein großer Teil der User hätte wahrscheinlich ein Problem ein Backup zu restaurieren. Normalen Anwender wird daher von GitHub Installationen abgeraten.
Ich hoffe, das war jetzt nicht zu negativ, sondern als gut gemeinte Erkenntnis gedacht
Ich konnet nichts negatives lesen.
-
Ich geh die Tage mal meine Adapter, die ich so nutze bzw. im Monitoring habe, mal durch ..
Beispiele wie Govee-App, BluelinkEs ist ja immer ein Katz und Mausspiel.. wenn Hersteller was ändern.
Am wenigsten Aufwand machen die Adapter, die nur lokal laufen und sich nichts an den Devices ändert.
-
also, ich bin auch nicht der meinung, das man hier mit adapter von gihub viel automatisieren sollte. aber jeder kann ja selbst machen was er will und in der lage ist.
um der eigentlichen frage mal eine mögliche lösung anbieten zu können könnte ich folgendes vorschlagen:
versionsnummern von adaptern in iobroker:
diese sind im systemdatenpunkt in den objektdaten gepeichert.
also für den admin adapter bspw
system.adapter.admin.0
wenn du in den expertenmodus gehst, und dir über die datenpunkt-settings den inhalt anschaust, dann findest du alle informationen, die auch in io-package.json des adapters gespeichert sind.Änderung am adapter auf github
wie auch schon erwähnt, eine versionsnummer muss nicht unbedingt geändert werden, wenn nicht auch nach npm gepublisht wird oder in ein iobroker repository (wo npm aber auch die voraussetzung ist)
allerdings besitzt gihub ja ebenfalls eine api, über die alle verfügbaren informationen abgerufen werden können, wie zb auch zeitpunkt des letzten commits.
über die stabilität des adapters auf basis des letzten commits sagt das natürlich nichts aus.Release auf npm
Auch npm hat eine api oder kann über den npm lokal abgerufen werden. eine suche nach einem adapter kann dann bspw so aussehennpm search iobroker.skiinfo --jsonals ergebnis kommt dann hier auch komfortabel ein json heraus was gut weiter verarbeitet werden kann,
