feat: support multi-platform build using buildx

[vigsterkr]

Currently only linux/amd64 docker images are being built, which causes the arm users to run the whole image in an emulator... this adds support for multi-platform builds.

[vigsterkr]

@SwissDataScienceCenter/yat i'm wondering if it makes sense to build all the platforms for the acceptance test as well. coz that'll adds some significant amount of build-time because of qemu

[rokroskar]

It looks like a docker push that is separate from the buildx command pushes just a single arch image, not the multi-arch. Maybe docker buildx build --push has to be used always?

[rokroskar]

Actually thinking more about this, we don't gain a lot by making the base images multi-platform because no one uses the base images directly. If anything, the gitlab ci jobs in the Renku projects themselves should make multi platform images so they can be used for local sessions. WDYT @olevski?

[olevski]

@rokroskar I agree, I think the majority of users will not need these. But if the CI pipelines in projects build multi platform images then wouldn't they need to start with these multi platform images? I.e. the base images would still be needed.

So if want to support multi platform images fully then we should do this PR and then also modify the project templates. Or mention in the docs how one can do this with gitlab ci.

[rokroskar]

I also thought so but it doesn't seem to be the case - basically you don't need everything in the dependency chain to be multi-arch.

[olevski]

Oh cool. Then we definitely do not need this @rokroskar. I propose we close this then.

[rokroskar]

haha well of course I'm talking nonsense. I think we should finish this PR... the base images for the jupyter stack are multi-arch so at least for our renku/renkulab-py image the multi-arch build makes sense. Rocker images don't seem to be multi-arch so for anything R-based it doesn't make sense to do multi-arch for now.

[rokroskar]

btw the reason I went down this rabbit hole again is because it turns out streamlit doesn't work on m1 running via qemu... so I had to build a native image to get it to work locally. 1.5 hours later I got it working... would have saved some time if I had a native base image 😅 Initially I thought the only issue would be a performance penalty but it turns out that some code just won't run.

[rokroskar]

This PR has taken quite a different turn than what was originally intended... a lot has changed in the meantime (mature standard docker actions, yay!). In trying to make the buildx builds work with our existing setup, I started needing to do a ton of environment variable gymnastics which would eventually very likely lead to everything breaking in some strange ways that would be hard to anticipate or detect. So I've instead opted to completely rewrite the workflow that builds the images to use the official docker actions for both generating metadata (no more brittle bash scripts) as well as building and pushing the images. I've also changed the base tags for the python images - instead of using lab-x.y.z which is a pretty meaningless entity from our pov, I've used the python versions - 3.10 (default), 3.9 and 3.8. Note that these will probably change - the jupyter/base-notebook images that we rely on do get updated afaik so in a follow-up we might want to pin those further.

The basic setup now is:

1. build the python base images for testing in the first step. These are just tested, and only the 3.10 (current default python version) is pushed so it can be used in the subsequent builds (we copy the renku virtualenv from this base image into all the other ones).
2. in the second phase, build all the images for pushing to dockerhub. This now includes a step that builds and pushes the multiarch python images (the original purpose of this PR). No other images are made for arm64 at the moment - we should watch rocker/rstudio for apple silicon linux/arm64/v8 platform rocker-org/rocker-versioned2#144 to see when the standard rocker images support arm64.
3. three different tags are generated: commit-sha (on every push), latest (on push to master) and semver on tags. I've tested that tagging works as intended here.

In a follow-up, we should consider changing this a bit further an push the CI images to something other than docker hub to avoid too much pollution and confusion with "official" images.

I also tried to use some sensible caching here but the layers change in ways that I don't really understand so the cache hits are few and far between. This can be investigated in a follow-up...

In addition, to actually get this multiarch goodness to the users, we need to add support for it to the gitlab-ci scripts in the renku project template. See SwissDataScienceCenter/renku-project-template#178.

[olevski]

One question about the multi-stage builds. I think we can push more things into the 1st stage?

[olevski]

One question about the multi-stage builds. I think we can push more things into the 1st stage?

EDIT: I answered my own question. Things are just copied into the last stage from the build stage. So there are no other steps that are as easy to move into the build stage other than the python virtual env.

[rokroskar]

Thanks for reviewing @olevski and thanks for kicking this off all those months ago @vigsterkr!! 🙌