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

[OliverIO]

Am 17.9. fand das letzte developer meeting statt.
Im Zuge dessen habe ich auch die Einstufung von manchen Fehler/Warnungen/Suggestions angesprochen.

Klar ist, der repochecker ist schon hilfreich und gibt insbesondere Anfänger in der Adapterentwicklung wichtige Hinweise, was noch zu verbessern wäre, irgendwo noch etwas fehlt oder konkret falsch eingestellt ist.
Allerdings gibt es mit den unterschiedlichen Wissens-Levels auch unterschiedliche Bedarfe.

Auch sehe ich es so, das der repochecker so früh als möglich selbst durch einen Anwender ausgeführt werden kann, so das er nicht erst auf den Automatismus warten muss, sondern als Prüfinstrument ob der Adapter nun richtig konfiguriert ist, so das er auch in das beta repository aufgenommen werden kann.

Für alle meine Adapter habe ich aktuell jeweils einen Issue des repocheckers mit Warnungen, bei denen ich aber selbst beschlossen habe der Warnung nicht zu folgend. Leider kann man den zwar schließen, aber er erscheint nach einiger Zeit wieder erneut mit den gleichen Warnungen.

Klar ignoriere ich aktuell diesen, aber mein innerer Monk hat eigentlich eher das Ziel 0 Issues.

Um dieses "Problem" anzugehen, gäbe es verschiedene Möglichkeiten

repochecker konfigurierbar machen um bestimmte Fehlerkategorien Warning/Suggestions auszublenden oder gar auf konkrete Nummer bspw W156 nicht zu reagieren (lokal, aber auch bei automatischer Prüfung)

repochecker lokal ausführbar machen (funktioniert eigentlich schon)

Kategorisierung von einzelnen Warnungen anpassen, so das bestimmte Warnungen eigentlich nur suggestions sind, die aber nur einmalig angemerkt werden oder komplett ausgeblendet werden.

Wenn man die Kategorien definieren müsste, dann wäre meine Definition die folgende:

Error: Probleme, die auf jeden Fall behoben werden müssen. die auch ein nächstes Release bzw auch eine Aufnahme in das beta-repository verhindern

Warnings: Probleme die ein konkretes Release nicht verhindern, aber ggfs die Aufnahme in das Beta-repository.

Suggestions:
Probleme die aktuell noch in Ordnung sind, aber irgendwann in der Zukunft relevant werden
Paket-Empfehlungen (bspw fetch statt request oder axios)
Allerdings dürfen suggestions maximal einmal angemerkt werden.
Suggestions sehe ich eher in einer Themensortierten Liste auf dem dev-Portal. Wenn man das dann doch automatisiert haben möchte, dann mit der Option suggestions optional auszublenden.

Damit insbesondere Anfänger mit der kompletten Bandbreite auch arbeiten, könnte man im adapter-createor die option zum lokalen ausführen des repocheckers gleich mit einbauen. Wenn jemand bspw suggestions nicht haben möchte, kann er das mit der entsprechenden Option auch wieder ausblenden

Optional wäre auch ein Plugin für das release Skript denkbar, welches ein release nach den obigen (oder gemeinsam zu definierenden) Kriterien für die Kategorien ein Release durchführt oder nicht.

Die beiden letzten Punkte würde die Anzahl der try und error Versuchen reduzieren und direktes Feedback für den Entwickler erzeugen.

[OliverIO]

Hier die beiden Meldungen + Issues zum Post.
Von anderen wurden weitere Issues erzeugt.

https://github.com/ioBroker/ioBroker.repochecker/issues/514
https://github.com/ioBroker/ioBroker.repochecker/issues/531

[Jey Cee]

@oliverio ich bin auch der Meinung das der Repochecker Sinnvoller weiße lokal ausgeführt werden sollte.
Das ganze als Plugin für das Release Skript zu machen finde ich nicht schlecht.

Was die Meldungen angeht, ich habe bereits angeregt Zusätzlich zu den Meldungen PRs mit den nötigen Änderungen zu erstellen und diese dann zu verlinken.
https://github.com/ioBroker/ioBroker.repochecker/issues/519