-
-
Notifications
You must be signed in to change notification settings - Fork 574
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiarch images #394
Comments
Yes, that would be really great to have. But we have different dockerfiles for different architectures because of the complexity of the environment. At the time of writing the CI/CD there was no support (or just i was not able to find a way) for this in docker buildx. PR to rework CI/CD to support this functionality are welcome, maybe things habe changed over the years. |
I started to look into .docker and GHA workflows, i see there is a base image used as base (hihi) for later images and a lot of version for intel or other thing.
How's the overhead for different image (VAAPI/Nvidia, ..) ? Could it be reunite in one image for the sake of simplicity ? Anyway if i'll find time i'll try to make something and upgrade action version at the same time. Is every Dockerfile up to date ? |
Actually i think base image is not needed, we can directly build final image and avoid another step. And in the mean time step-up to Bookworm. |
Not having base image would mean, the build provides needs to be copied over to every single image that we are building. I can think of some dockerfile generator that would prepare such dockerfiles without having code duplication. But on the other hand i would like to keep the build process as simple as it can be. |
Check this. The second way to do it is to manually create manifests with Note that arm64 (or any other architecture built with GitHub Actions using QEMU emulation) is 6 times slower than amd64. |
DH & GHCR don't seem to support multiarch for Neko, I found separate images do and I checked the GH Actions workflow and it adds an “arm” prefix.
Wouldn't it be more logical and practical to use the same image name with the different architectures available?
The goal for me is to put something like ghcr.io/neko:firefox and get the right image for AMD64 and ARM64 with the same compose file.
++
The text was updated successfully, but these errors were encountered: