Gladys v4.0.5 erstellen

@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.

Github Action läuft hier:

https://github.com/GladysAssistant/Gladys/runs/1805214841?check_suite_focus=true

Ich bin zuversichtlich :smiley:

Na toll, es hat funktioniert, aber es baut nicht mehr wie früher :stuck_out_tongue:

Hier sind die Tags, die auf Docker Hub erzeugt wurden:

  • latest
  • v4
  • v4.0.5

(siehe mein Repo)

Früher hatten wir:

  • latest
  • v4
  • v4.0.5
  • v4-arm
  • v4-amd64
  • v4-arm32v7
  • v4-arm64v8

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!

Ist es kompliziert, diese Tags hinzuzufügen? :slight_smile:

Ach das ist ja eine Dummheit

buildx löst dieses Problem.

Das soll vor allem nicht so verwendet werden. Das Tag nach Architektur hat keinen Sinn.
Darum muss ich mich kümmern.

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

Es gibt keine Vorwürfe, übrigens erinnere ich mich an den Bug mit dem Manifest.

Im „manuellen“ Modus :confused:

Seit 2014 :slight_smile: , man muss die Versionen prüfen, aber ich glaube nicht, dass das ein Problem sein wird

Wer weiß?

Ich kann nur sagen, dass keiner meiner Container spezifische Tags für die Architektur hat


Egal, das eigentliche Problem ist woanders

  • Entweder machen wir einen etwas schmutzigen Flow mit Skripten (wie wir es mit CircleCI gemacht haben)
    → Die schnelle Build, Cache etc. vergessen wir
  • Oder wir erklären, wie man auf bestehenden RPIs aktualisiert
    → Nicht ideal für die Nutzer und die Kommunikation dazu

Es gibt keine gute Lösung, jetzt ärgert es 500 Nutzer, in 2 Jahren vielleicht das Doppelte?

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?

Nein, man kann keine spezifische Architektur pullen, daher kann man auch nicht hinterher umtaggen.

Ich habe eine Idee: Wir holen den SHA des Manifests, um einen Pull durchzuführen und dann zu retaggen. :sweat_smile:

würde das funktionieren? :stuck_out_tongue: Wenn es wirklich funktioniert aha

In der Theorie :woozy_face:

docker manifest inspect pierregilles/gladys-test:latest

{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2848,
         "digest": "sha256:51fc90d1e9d0f933953164554e6f05de59aa9df132eb7e258a591226314f7fa4",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2848,
         "digest": "sha256:6a8263c315c195cc6b9c773eaabff8b2c90ada263883850d4927520bdac8b2f0",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v6"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2848,
         "digest": "sha256:a2a55c324de662c01c8ad298c614488ac098e90601312ab402acba517dfbc122",
         "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v7"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2848,
         "digest": "sha256:2837f9ec94696ee168b5b045eee8027ef3d1c0be4d080730220cade2a6323a43",
         "platform": {
            "architecture": "arm64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 2848,
         "digest": "sha256:73660db5122e02479efa19e4bdd34d5006a601730c1edeeab525885e3660ff39",
         "platform": {
            "architecture": "s390x",
            "os": "linux"
         }
      }
   ]
}

Das Manifest enthält die Info (Pull mit dem Digest), aber man kann trotzdem eine Plattform pullen (ich weiß nicht, ob das neu ist).

docker pull pierregilles/gladys-test:v4 --platform arm (das arm/v7-Image wird gepullt)

image

Ich werde das testen und schnell einen Vorschlag machen, um den Stau zu lösen

Super! Lass mich wissen, wie es läuft :slight_smile:

      -
        name: 🐳 Legacy Tags
        run: |
          echo "::set-env name=DIGESTARM::$(docker manifest inspect ${{ env.DOCKERHUB_REPO }}:latest | jq -r '.manifests | to_entries[] | select(.value.platform.architecture == "arm" and .value.platform.variant == "v6").value | .digest')"
          docker pull ${{ env.DOCKERHUB_REPO }}@${{ env.DIGESTARM}}
          docker tag ${{ env.DOCKERHUB_REPO }}@${{ env.DIGESTARM}} ${{ env.DOCKERHUB_REPO }}:v4-arm
          docker push ${{ env.DOCKERHUB_REPO }}:v4-arm

Build läuft

Die Logik ist wie folgt:

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

Für diejenigen, die einen Live-Fail wollen ^^ => https://github.com/VonOx/GLADYS_CI/actions/runs/528130905

:crossed_fingers:

Genial! Das muss auch für diese mindestens gemacht werden:

  • v4-amd64
  • v4-arm64v8

Sie werden auch verwendet

Das funktioniert, ich bereite einen sauberen PR für dich vor

https://hub.docker.com/repository/docker/vonox/gladys/tags?page=1&ordering=last_updated

@VonOx Danke für das PR! Es ist gemerged, und es läuft hier: https://github.com/GladysAssistant/Gladys/actions/runs/531432836

Das ist build :smirking_face: (2 Minuten mit dem Cache)

Beeindruckend :heart_eyes: gut gemacht @VonOx :clap::clap:

Am Ende dauert der Legacy-Tag 50 Sekunden, das geht, ist nicht so schlimm :slight_smile:

Ja, das ist nur Bandbreite (Pull/Push).

Vielleicht gibt es eine elegantere Lösung, aber so funktioniert es ohne den Build-Zeit zu verschlimmern.

Ich habe das Bild getestet, alles funktionierte, also habe ich das Geheimnis geändert, damit es auf gladysassistant/gladys veröffentlicht wird, und habe den Build neu gestartet! Hier weiter: https://github.com/GladysAssistant/Gladys/actions/runs/531432836