Container tag v9.4.2 switched to Debian

[xoxys]

Hello,

It looks like with the v9.4.2 tag the container has changed from Alpine to Debian. Was this an intended change, as this could be a breaking change for some people (like us) who extend the image for their needs.

From the commit https://github.com/cs3org/wopiserver/commit/49fae003efe66a98deb78910247d965c318244d3 it appears that Alpine should still be used for the linux/amd64 platform image. However, I think it is generally a bad idea to change the base image depending on the platform.

[glpatcern]

Hi,

This is not an intended change, and the build job at https://github.com/cs3org/wopiserver/actions/runs/4290721714/jobs/7475033017 does show that the Alpine image was used. However, I could see by spinning up the v9.4.2 tag that the image appears to be Debian and not Alpine (e.g. apt is there and not apk).

Making the image parameterized was a consequence of #110, see there for the reasoning behind.

Do you have any suggestion why the GitHub action ended up building a Debian image despite logging that it took an Alpine image? For what it's worth, also the VERSION has gone missing in the built image. Maybe @vascoguita can shed some light as he spent quite some time now with GitHub actions and workflows for Reva.

[xoxys]

Sorry, Im not that familiar with GH Actions, no idea why the result in DockerHub is wrong.

[glpatcern]

OK, we suspect that as docker did not separate the images by arch, they raced and arm64 overwrote amd64. To be fixed by explicitly tagging arm64 as such.

[vascoguita]

There are some errors on the workflow. GH would only setup QEMU for multi-platform build if matrix.platforms != '' but the matrix parameter is called matrix.platform so QEMU setup was always skipped. There are other problems... I'm on it - https://github.com/cs3org/wopiserver/pull/114

[xoxys]

I still think using a different base OS for different platforms is not a good idea. I know that some wheels are not available for arm on Alpine, but using a multi-stage build to compile and copy those wheels or just adding the required compilers to the Dockerfile and removing them again as the last step would be a better approach than using a different base OS.

[vascoguita]

I still think using a different base OS for different platforms is not a good idea. I know that some wheels are not available for arm on Alpine, but using a multi-stage build to compile and copy those wheels or just adding the required compilers to the Dockerfile and removing them again as the last step would be a better approach than using a different base OS.

That would be indeed the perfect solution. If you manage to do that it will simplify things a lot. With the current Dockerfile I'll have to do some gymnastics to merge separately built images for different architectures under the same tag in dockerhub: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/ ("The hard way with docker manifest" section)

[xoxys]

Still not that deep into GH Actions, but I would recommend looking into buildx these days to avoid the manifest mess.

https://github.com/docker/setup-buildx-action https://github.com/docker/build-push-action

[vascoguita]

https://github.com/cs3org/wopiserver/pull/114 fixed the problem. I'm closing this issue.

[d7oc]

Just for the record as I just stumbled about this old issue. Having two different base images is really a very bad idea. This just took me a lot of time in https://github.com/owncloud/ocis/pull/7084 as one image "knows" bash and the other doesn't and you will even have the same SHA of the image in registries:

> docker run -d --platform linux/amd64 cs3org/wopiserver@sha256:17ff7c9b88086f446b81f8c108065e2d1b83cbd0bdf717eaa0f6e103d0be7caa          
Unable to find image 'cs3org/wopiserver@sha256:17ff7c9b88086f446b81f8c108065e2d1b83cbd0bdf717eaa0f6e103d0be7caa' locally
docker.io/cs3org/wopiserver@sha256:17ff7c9b88086f446b81f8c108065e2d1b83cbd0bdf717eaa0f6e103d0be7caa: Pulling from cs3org/wopiserver
Digest: sha256:17ff7c9b88086f446b81f8c108065e2d1b83cbd0bdf717eaa0f6e103d0be7caa
Status: Downloaded newer image for cs3org/wopiserver@sha256:17ff7c9b88086f446b81f8c108065e2d1b83cbd0bdf717eaa0f6e103d0be7caa
678b55b53424ad14f92c7b315b376f507aa70125cf9fdf64503addf634491c13
> docker exec -it 678b55b53424ad14f92c7b315b376f507aa70125cf9fdf64503addf634491c13 bash
OCI runtime exec failed: exec failed: unable to start container process: exec: "bash": executable file not found in $PATH: unknown
> docker stop 678b55b53424ad14f92c7b315b376f507aa70125cf9fdf64503addf634491c13
678b55b53424ad14f92c7b315b376f507aa70125cf9fdf64503addf634491c13
> docker rm 678b55b53424ad14f92c7b315b376f507aa70125cf9fdf64503addf634491c13
678b55b53424ad14f92c7b315b376f507aa70125cf9fdf64503addf634491c13
> docker run -d --platform linux/arm64 cs3org/wopiserver@sha256:17ff7c9b88086f446b81f8c108065e2d1b83cbd0bdf717eaa0f6e103d0be7caa        
Unable to find image 'cs3org/wopiserver@sha256:17ff7c9b88086f446b81f8c108065e2d1b83cbd0bdf717eaa0f6e103d0be7caa' locally
docker.io/cs3org/wopiserver@sha256:17ff7c9b88086f446b81f8c108065e2d1b83cbd0bdf717eaa0f6e103d0be7caa: Pulling from cs3org/wopiserver
[..]
Digest: sha256:17ff7c9b88086f446b81f8c108065e2d1b83cbd0bdf717eaa0f6e103d0be7caa
Status: Downloaded newer image for cs3org/wopiserver@sha256:17ff7c9b88086f446b81f8c108065e2d1b83cbd0bdf717eaa0f6e103d0be7caa
62af3a75a5e6b3c60a103efd5ab0097f5502e2bf4050b8caa3c53bfc09cad71e
> docker exec -it 62af3a75a5e6b3c60a103efd5ab0097f5502e2bf4050b8caa3c53bfc09cad71e bash
root@62af3a75a5e6:/app# exit

I would be really happy if this could be addressed.