@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 
Bon ça a marché, mais ça ne build pas comme avant 
Voilà les tags produits sur Docker hub:
(cf mon repo)
Avant on avait:
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? 
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 :
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 » 
Depuis 2014 
, 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à
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. 
ça marcherait ça ? Si ça marche carrément aha
En théorie 
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
-
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 ^^ => https://github.com/VonOx/GLADYS_CI/actions/runs/528130905
Génial! Il faudra le faire à minima pour ceux-là aussi:
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
@VonOx Merci pour la PR ! C’est merge, et ça tourne ici : 4.0.6 · GladysAssistant/Gladys@9bbe54d · GitHub
C’est build 
(2 minutes avec le cache)
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
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
bien joué 