alternatives Docker Image

[bmx]

... dann auch der Ansatz mit den GitHub Actions

Aktuell verwenden Core und Plugins die Github Actions zum automatisierten Testen

[henfri]

henfri, SaschaG Sollten wir auf DockerHub eine Organisation SmarthomeNG gründen? Dann könnten wir ein "offizielles" Docker Image bauen...

Ja, gerne!

[jentz1986]

henfri - Ich hätte den Knopf "create organization" vorher drücken sollen, bevor ich hier das mit der Organisation poste. Das kostet mindestens 35 EUR/Monat. Das würde ich bei aller Liebe fürs Thema nicht persönlich ausgeben wollen. Zumal der Wert ja nur ist, dass man den Container dann von mehreren Ecken erstellen kann. Aber das geht mit Github Actions ja auch, weil man den Workflow dann über Berechtigungen aufs Repository steuern kann.

Aktuell verwenden Core und Plugins die Github Actions zum automatisierten Testen

Wieviel von den 2000 kostenfreien Minuten pro Monat wird da bisher genutzt? Einmal Container bauen und auf dem Hub veröffentlichen sind ca. 5 Minuten - hab ich gestern getestet 😁.

[bmx]

jentz1986 Du kannst höchstens mal auf https://www.docker.com/community/ope...e/application/ schauen, ob das auch kostenlos geht für Open Source Projekte

[SaschaG]

Hallo

Ich denke es ergeben sich verschieden Fragestellungen die wir evtl. aufsplitten sollten:

1. Wann tellen wir den Usern ein aktuelles Image zur verfügung? Hier sit der Verbreitungsweg evtl. egal. Ich würde aber den existierenden "offiziellen" Weg über Hendrik bevorzugen.
2. Wie arbeiten wir zusammen? Die Codebase auf Github von Hendrik scheint mir dafür ausreichend.
3. Wie binde ich User Plugins mit ein?
   1. Hendriks Vorschlag: Manuelles Mounten der Plugins. Vorteil: Native Docker Bordmittel. Nachteil: Kann bei vielen Plugisn unübersichtlich werden.
   2. Jentz Vorschlag: Kopieren von (ZIP?) Datein in das Image? Vorteil? Einfacher zu konfigurieren. Nachteil: Neustart für Update?
   3. Neuer Vorschlag: Mounten aller Plugins unter einem bestimmten Pfad. Vorteil: Einfach zu konfigurieren. Direktes bearbeiten der Dateien möglich. Nachteil: ?

Gruß
Sascha

[jentz1986]

Hi!

Ich würde aber den existierenden "offiziellen" Weg über Hendrik bevorzugen.

Don't fix what is not broken :-) Gerne! Der einzige Haken daran ist, dass damit die Arbeit bei henfri liegt und nicht verteilt werden kann. Das wäre bei der Organisation besser, aber hmm. henfri kannst Du Dir vorstellen ein DockerHub Personal Access Token in die GitHub Secrets zu packen? Dann könnten wir die Berechtigungen für das Docker-Repo erweitern und trotzdem den bewährten Distributionskanal verwenden.

Codebase auf Github

Das ist das Entscheidende - eine Codebase. Die Zusammenarbeit erfolgt über Pull Requests und Code-Reviews. Sprechende Commit-Kommentare retten die Kommunikation und Feature/Strategiediskussionen dann von mir aus hier oder über Gitter. Mein Fork ist aus der "Not" geboren, die Dinge nachvollziehbar zu teilen ohne das Original in Frage zu stellen und nicht, weil ich was eigenes aufziehen will. henfri Machst Du das Quality-Gate, ich stell dann einen Pull-Request?

Wie binde ich User Plugins mit ein

Mein Vorschlag ist der: Nutze ein Plugins-Default Verzeichnis im Image um die Standard Plugins aus dem Repo "vollständig" vorzuhalten. Das Einkopieren der Plugins aus dem Plugins Verzeichnis außerhalb des Containers passiert nur für die Plugins an denen man fummelt. Vorteil: Einfach das Verzeichnis löschen, das stört, und sofort nach dem Containerneustart ist alles wieder fein. In meiner Pipeline zuhause führt jede Konfigurationsänderung zu einem Containerneustart, und alle Plugins werden aus den jeweiligen individuellen Repositories neu geladen (dauert <2 sek). Damit zwinge ich mich über Git zu arbeiten und meine Änderungshistorie nachzuhalten.

Mounten aller Plugins unter einem bestimmten Pfad.

Hatte ich auch überlegt, aber das sind schon echt viele Plugins und das ist auch unübersichtlich. Um hier dann wieder "auf Standard" zurückzukommen muss man wieder git bemühen.

Ich würde für das Gesamtsystem irgendwie gerne dahin kommen, dass die Plugins jeweils einzeln in Github-Repositories liegen und man quasi nur eine Registrierung (Ähnlich "Packagesource") in das offizielle Repo macht, um die Plugins versionskontrolliert an das offizielle Release zu binden (ich glaube HomeAssistant macht das auch so). Dann könnte man den Usern auch die Möglichkeit geben, über die GUI ein Git-Repo als Plugin-Quelle zu definieren, zack ist das ganze Problem gelöst und das Ökosystem kann florieren, damit lässt sich auch das "Lizenzproblem" lösen, wenn man dritten Code im Plugin nicht über pip-Sourcen einbinden kann. Das ist natürlich ein vollständiger Strategiewechsel und sicher nicht in einem Release getan. Und wahrscheinlich übersehe ich noch sechshundertdrölfzigtausend Gründe die dagegen sprechen. Evtl. ist diese Diskussion aber einen eigenen Thread wert.

Zurück zum Container:
Ich bin übrigens nicht so der "Linux-Admin" - d.h. die ganzen chown, gosus etc. verstehe ich zwar grob, aber so richtig fit erlebe ich mich darin nicht. D.h. das was ich jetzt ergänzt habe muss von jemandem, der/die/* das kann nochmal gecheckt und ggf. ergänzt werden.
Was ich auch noch nicht gerafft habe ist das Faktum, dass ich bei mir immer noch ein chmod +x für die Entrypoint/Wrapperscripte machen musste um den Container lauffähig zu bekommen. Ich finds zwar logisch und konsequent, frage mich aber, warum das in euren Varianten bisher nicht nötig war...

Danke fürs Lesen bis hierhin 🙃

Grüße,
Jens

[jentz1986]

Du kannst höchstens mal auf https://www.docker.com/community/ope...e/application/ schauen, ob das auch kostenlos geht für Open Source Projekte

Die Seite liest sich ja so, dass das passt. Ich würde mir jetzt nur nicht einfach so anmaßen für SHNG zu sprechen... Aber ich kann das gerne versuchen voran zu treiben, wenn ich von den offiziellen Maintainern das OK bekomme. henfri / SaschaG bzw. bmx / Msinn / psilo / Onkelandy

[Onkelandy]

Ich denke, das ganze Projekt lebt von der Community und der Tatsache, dass es auf verschiedenen Wegen zugänglich wird. Ein "offizielles" Dockerimage, um das sich mehrere Leute außerhalb vom Core kümmern, begrüße ich sehr.
Morg ist übrigens auch im Coreteam.

[henfri]

Aber ich kann das gerne versuchen voran zu treiben, wenn ich von den offiziellen Maintainern das OK bekomme. henfri / SaschaG bzw. bmx / Msinn / psilo / Onkelandy

Na klar bin ich einverstanden!

[SaschaG]

@Jentz: Immer gerne.

[rey]

SaschaG: bei mir läuft die "med/latest" Variante problemlos, lediglich wird das Influxdb2 Plugin (noch im dev status) nicht gefunden. Muss ich dann auf die "full" Variante wechseln oder kann ich dieses Plugin für die "med/latest" Variante nachinstallieren? Ich nutzte eine Synology NAS.

Danke vorab.

[jentz1986]

Probier mal mein o.g. Image. Das plugin braucht 1.9.2 und das Image von Sascha ist noch auf 1.9.1.

Ich kümmere mich nächste Woche (Urlaub) um die Docker Organisation und dann dürfte das alles etwas flüssiger gehen.

EDIT: hier die Dockerhub Referenz:

jentz1986/smarthomeng:v1.9.2beta0

[rey]

danke! (die Frage gabs sogar schon im Thread - wer lesen kann ist klar im Vorteil 🙈)

Danke für eure Arbeit!

[jentz1986]

image.png
jetzt einen 30 Tage Trommelwirbel :-)

[henfri]