Build Gladys v4.0.5

@VonOx Pour info, j’ai lancé un build release sur Github, Gladys v4.0.5 (le premier build depuis Github action!)

J’ai changé dans les paramètres du repo pour que ça push le résultat sur un repo dockerhub pourri (pierregilles/gladys-test), et ensuite si tout va bien, je re-changerais le repo dans les secrets et je relancerais le build pour que ça push sur le bon repo.

Github action tourne ici:

Je suis confiant :smiley:
image

Bon ça a marché, mais ça ne build pas comme avant :stuck_out_tongue:

Voilà les tags produits sur Docker hub:

  • latest
  • v4
  • v4.0.5

(cf mon repo)

Avant on avait:

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

On a besoin de ces tags, car l’image Raspbian est basée sur le tag v4-arm par exemple.

Pour info, l’histoire du Docker manifest avec Docker qui « détecte » la plateforme que tu utilise, ça ne marche pas si bien que ça (quand j’avais fais mes tests, ça ne marchait pas).

Pour l’instant on a toujours mis en avant ces tags dans la documentation, et toutes les instances qui tournent se basent dessus!

C’est compliqué à rajouter? :slight_smile:

Ah ça par contre c’est une bétise

buildx règle ce problème.

C’est surtout pas censé être utilisé comme ça. Le tag by arch n’as pas de sens.
Je dois y réfléchir.

C’est comme ça, à l’époque ça ne fonctionnait pas, il fallait bien sortir l’image ^^

Maintenant oui mais jusque là tous les projets faisait comme ça. Watchtower fait comme ça aussi!

Après maintenant c’est trop tard, on a environ 500 instances qui utilisent ce tag en production, pas de retour en arrière possible, à voir si on passe à l’image v4 pour les nouvelles images mais il faut continuer à supporter l’existant.

Aussi, même pour une nouvelle image Raspbian, je pense qu’il y a toute une réflexion à avoir avant de passer à cette détection d’image automatique :

  • Est-ce que ça marche avec toutes les version de Docker ? (Quid des gens qui ont des syno bloqué en Docker sorti avant la version qui supportaient la détection de plateforme?)
  • Est-ce c’est si stable que ça, et est-ce que ça ne risque pas de nous bloquer à l’avenir ?

Au moins, je trouve la méthode actuelle bien plus safe pour l’utilisateur finale

Y’a pas de reproche, d’ailleurs je me rappel du bug avec le manifest.

En mode « manuel » :confused:

Depuis 2014 :slight_smile: , faut checké les versions mais je penses pas que celà soit un problème

Who knows ?

A part te dire qu’aucuns de mes conteneurs n’a de tags spécifique à l’arch


De toute façon le débat n’est pas vraiment là

  • Soit faut refaire un flow un peu crado à base de script( ce qu’on faisait avec circleci )
    → La fast build ,cache etc… on oubli
  • Soit on explique comment update sur les RPI existants
    → Pas terrible pour les users et la comm qui va avec

Y 'a pas de bonne solution, maintenant ça « emmerde » 500 utilisateurs , dans 2 ans peut être le triple ?

Cette option n’est pas envisageable, on est plus en beta, il faut raisonner comme si les 500 maisons faisant tourner Gladys étaient « figée » et qu’on devait les supporter.

Avec la v4 on veut véhiculer une image de stabilité sur le long terme, si on arrête de supporter une image seulement 2 mois après sa sortie ça la fout mal ^^ Surtout si c’est juste pour pas s’embêter, là il n’y a pas de blocage technique.

On peut pas faire un mix des deux ?

buildx + on tag des images v4-arm à base de l’image v4 manifest arm ?

docker tag + docker push dans une étape séparé ?

Non on peut pas pull une arch spécifique donc on peut pas retag derrière

J’ai une idée on récupère le sha du manifest pour faire un pull puis retag. :sweat_smile:

ça marcherait ça ? :stuck_out_tongue: Si ça marche carrément aha

En théorie :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"
         }
      }
   ]
}

Le manifest a l’info(pull avec le digest) , mais a priori on peut quand même pull une platform ( je sais pas si c’est récent ).

docker pull pierregilles/gladys-test:v4 --platform arm ( l’image arm/v7 est pull )

Je vais tester ça et faire une proposition rapidement pour débloquer

Top ! Tiens moi au courant :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 en cours

La logique est la suivante:

1- Quand le build global est terminé, je récupère le digest de l’image armv6
2- Je pull cette image par son digest
3- Je tag l’image en v4-arm
4- Je push

Pour ceux qui veulent un fail en live ^^ => Update docker-release-build.yml · VonOx/GLADYS_CI@e05ff16 · GitHub

:crossed_fingers:

Génial! Il faudra le faire à minima pour ceux-là aussi:

  • v4-amd64
  • v4-arm64v8

Ils sont utilisés aussi

ça fonctionne , je te prépare une PR propre

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

2 Likes

@VonOx Merci pour la PR ! C’est merge, et ça tourne ici : 4.0.6 · GladysAssistant/Gladys@9bbe54d · GitHub

C’est build :smirk:(2 minutes avec le cache)

Impressionnant :heart_eyes: bien joué @VonOx :clap::clap:

Au final le tag legacy ça prend 50 secondes, ça va c’est pas si mal :slight_smile:

Oui c’est que de la bande passante ( pull / push )

Y’a peut être moyen de faire plus élégant mais ça fait le taff sans pourrir le temps de build

1 Like

J’ai testé l’image, tout fonctionnait, j’ai donc changé le secret pour que ça publish sur gladysassistant/gladys et j’ai relancé le build! A suivre ici: 4.0.6 · GladysAssistant/Gladys@9bbe54d · GitHub