@VonOx For information, I launched a release build on Github, Gladys v4.0.5 (the first build from Github action!)
I changed the repository settings to push the result to a crappy Docker Hub repository (pierregilles/gladys-test), and then if everything goes well, I will change the repository in the secrets and restart the build to push to the correct repository.
Github action is running here:
https://github.com/GladysAssistant/Gladys/runs/1805214841?check_suite_focus=true
It worked, but it doesn’t build like before 
Here are the tags produced on Docker Hub:
(cf my repo)
Before we had:
We need these tags, for example the Raspbian image is based on the v4-arm tag.
For information, the Docker manifest story with Docker « detecting » the platform you use doesn’t work so well (when I did my tests, it didn’t work).
So far we have always highlighted these tags in the documentation, and all running instances are based on them!
Is it complicated to add? 
Oh that’s nonsense
buildx solves this problem.
It’s not supposed to be used like that. The tag by architecture doesn’t make sense.
I need to think about it.
That’s how it was, it didn’t work at the time, you had to get the image out ^^
Now yes but until now all projects did it that way. Watchtower does it too!
After now it’s too late, we have about 500 instances that use this tag in production, no going back possible, we’ll see if we move to the v4 image for new images but we have to continue to support the existing ones.
Also, even for a new Raspbian image, I think there’s a whole reflection to be had before moving to this automatic image detection:
At least, I find the current method much safer for the end user
No blame, by the way I remember the bug with the manifest.
In « manual » mode 
Since 2014 , you need to check the versions but I don’t think that will be a problem
Who knows?
Apart from telling you that none of my containers have tags specific to the architecture
In any case, the debate is not really there
There is no good solution, now it « bothers » 500 users, in 2 years maybe three times as many?
This option is not feasible, we are no longer in beta, we need to think as if the 500 houses running Gladys were « frozen » and that we had to support them.
With v4, we want to convey an image of long-term stability. If we stop supporting an image just two months after its release, it looks bad ^^ Especially if it’s just to avoid the hassle. There is no technical blockage here.
Can’t we mix the two?
buildx + tag images v4-arm based on the v4 manifest arm?
docker tag + docker push in a separate step?
No, you can’t pull a specific architecture, so you can’t retag afterward.
I have an idea, we retrieve the manifest’s sha to do a pull then retag. 
Would that work? If it works perfectly aha
In theory 
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"
}
}
]
}
The manifest has the info (pull with the digest), but a priori you can still pull a platform (I don’t know if this is recent).
docker pull pierregilles/gladys-test:v4 --platform arm (the arm/v7 image is pulled)
I will test this and make a proposal quickly to unblock
Great! Keep me posted
-
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 in progress
The logic is as follows:
1- When the global build is complete, I retrieve the digest of the armv6 image
2- I pull this image by its digest
3- I tag the image as v4-arm
4- I push
For those who want a live fail ^^ => https://github.com/VonOx/GLADYS_CI/actions/runs/528130905
Great! We’ll need to do this for these as well:
They are also used
It works, I’ll prepare a clean PR for you
https://hub.docker.com/repository/docker/vonox/gladys/tags?page=1&ordering=last_updated
@VonOx Thanks for the PR! It’s merged, and it’s running here: https://github.com/GladysAssistant/Gladys/actions/runs/531432836
It’s build 
(2 minutes with the cache)
Amazing 
well done @VonOx 
In the end, the legacy tag takes 50 seconds, it’s okay, it’s not that bad
It’s just bandwidth (pull/push)
There might be a more elegant way to do it, but it works without messing up the build time.
I tested the image, everything was working, so I changed the secret to publish to gladysassistant/gladys and I restarted the build! Follow here: https://github.com/GladysAssistant/Gladys/actions/runs/531432836