Docker pull does not load correct arch image on arm64

[roycec]

• Gitea version (or commit ref): 1.9.1
• Git version:
• Operating system: Ubuntu 16.04.6 LTS (Xenial Xerus) on arm64
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • [] No
  • Not relevant
• Log gist:

Description

When I try to download the docker image with the 1.9.1 tag, I get the amd64 image. I'm only able to download the arm64 image, if I use 'docker pull gitea/gitea:linux-arm64'. But then I get the latest (development) version. But I want to use the last stable version, and I would expect the image for the correct architecture being downloaded. But I'm also not sure, if this is a Gitea thing or not.

[sapk]

The 1.9 branch doesn't have the change for multi-arch (merge after 1.9 freeze).
Only master and version after 1.9 will be multi-arch image.

[roycec]

So when there will be multiarch versions? Or how can I see, if multiarch images exist on dockerhub?

[sapk]

I prepare the backport, and let others maintainers choose if we need to backport it.
Normally the rule is to only backport fix after version freeze.

We will soon (less than 1 month) freeze 1.10 process so a 1.10-rc1 should be soon available and the 1.10.0 release could be expected 1 or 2 month later. This timeline is purely an estimation based on previous releases but it could maybe take longer.

[sapk]

To detect multi-arch image you can use the command docker inspect your/image:tag you will find the returned arch.

Edit: If you have experimental cli activated docker manifest inspect gitea/gitea vs docker manifest inspect gitea/gitea:1.9

[roycec]

ok, maybe this was a misunderstanding on my end. I thought, multiarch images would be created for every release. Or maybe this is the goal?

[sapk]

The backport PR is now merged so when 1.9.2 will also be released, the tags 1.9.2, 1.9, 1 will be multi-arch. Every release later will have multi-arch.

[techknowlogick]

Linked PR has been merged. Will close this issue now. Thanks for opening it, and thanks to @sapk for PR :)