@VonOx Nur zur Info, ich habe einen Release-Build auf Github gestartet, Gladys v4.0.5 (der erste Build seit Github Action!)
Ich habe in den Repo-Einstellungen geändert, damit das Ergebnis auf ein schreckliches Dockerhub-Repo (pierregilles/gladys-test) gepusht wird, und dann, wenn alles gut geht, ändere ich das Repo in den Secrets zurück und starte den Build erneut, damit es auf das richtige Repo gepusht wird.
Diese Tags sind notwendig, da das Raspbian-Image beispielsweise auf dem Tag v4-arm basiert.
Übrigens, die Geschichte mit dem Docker Manifest, bei der Docker die verwendete Plattform „erkennt“, funktioniert nicht so gut (als ich meine Tests gemacht habe, hat es nicht funktioniert).
Bisher haben wir diese Tags immer in der Dokumentation hervorgehoben, und alle laufenden Instanzen basieren darauf!
So war das damals, es hat nicht funktioniert, man musste das Bild einfach rausbringen ^^
Jetzt ja, aber bisher haben alle Projekte so gemacht. Watchtower macht das auch so!
Jetzt ist es zu spät, wir haben etwa 500 Instanzen, die diesen Tag in der Produktion verwenden, kein Zurück mehr möglich, aber wir werden sehen, ob wir für neue Bilder auf das v4-Bild umsteigen, aber wir müssen weiterhin die bestehende Lösung unterstützen.
Auch für ein neues Raspbian-Bild denke ich, dass man vor dem Umstieg auf die automatische Bilderkennung eine ganze Überlegung anstellen muss:
Funktioniert das mit allen Docker-Versionen? (Was ist mit den Leuten, die Synos haben, die mit einer Docker-Version vor der Version, die die Plattformerkennung unterstützt, blockiert sind?)
Ist das wirklich so stabil und riskiert es nicht, uns in Zukunft zu blockieren?
Zumindest finde ich die aktuelle Methode für den Endbenutzer viel sicherer
Diese Option ist nicht machbar, wir sind nicht mehr in der Beta-Phase, man muss so denken, als wären die 500 Häuser, die Gladys laufen lassen, „eingefroren“ und man müsste sie unterstützen.
Mit der v4 wollen wir ein Bild von Langzeitstabilität vermitteln. Wenn wir ein Image nur zwei Monate nach dessen Veröffentlichung nicht mehr unterstützen, sieht das nicht gut aus ^^ Besonders, wenn es nur ist, um sich nicht zu sehr zu bemühen. Hier gibt es keine technischen Hindernisse.
Können wir nicht eine Mischung aus beidem machen?
buildx + Tagging der Images v4-arm basierend auf dem v4-Manifest arm?
docker tag + docker push in einem separaten Schritt?
1- Wenn der globale Build abgeschlossen ist, hole ich den Digest des armv6-Images
2- Ich pull das Image mit seinem Digest
3- Ich tagge das Image als v4-arm
4- Ich push