Wanted to continue the discussion from #28 (comment) in a dedicated issue.
So I've looked into how these new multi-arch images work.
The last time I did some work on this it seemed like the image needed to be pushed for all architectures at the same time.
This seems to be the recommended and easiest way to handle multi-arch images.
However, I found a way to build these images independently and stitch them together afterwards (see "The hard way with docker manifest" https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/). This would require us to upload each image for each architecture with its own tag to the registry, then creating a new "tag" or manifest which combines them. Afterwards the initial tags can be deleted, because their layers are referenced by the new manifest.
Interestingly, the docker manifest create command is marked experimental and not recommended for production. On the other hand, there's docker buildx imagetools create, which might work the same way.
This is the best I can come up with, yet. I don't like the fact, that we're required to push the "intermediate" images first, and I'm not sure if that's an acceptable solution. Furthermore it would increase the complexity of the task. What do you think?
I also couldn't find 1) how to improve the readability of the logs (only through --output=plain) nor 2) allow individual architectures to fail, while keeping the successfully build, as alternative solutions.
Wanted to continue the discussion from #28 (comment) in a dedicated issue.
So I've looked into how these new multi-arch images work.
This seems to be the recommended and easiest way to handle multi-arch images.
However, I found a way to build these images independently and stitch them together afterwards (see "The hard way with docker manifest" https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/). This would require us to upload each image for each architecture with its own tag to the registry, then creating a new "tag" or manifest which combines them. Afterwards the initial tags can be deleted, because their layers are referenced by the new manifest.
Interestingly, the
docker manifest createcommand is marked experimental and not recommended for production. On the other hand, there'sdocker buildx imagetools create, which might work the same way.This is the best I can come up with, yet. I don't like the fact, that we're required to push the "intermediate" images first, and I'm not sure if that's an acceptable solution. Furthermore it would increase the complexity of the task. What do you think?
I also couldn't find 1) how to improve the readability of the logs (only through
--output=plain) nor 2) allow individual architectures to fail, while keeping the successfully build, as alternative solutions.