Self-contained docker build with ARM64 publishing #3962
Conversation
| RUN ./mill -i copyTo --task 'cli[].base-image.nativeImage' --dest "./docker-out/scala-cli" 1>&2 | ||
|
|
||
| FROM debian:stable-slim | ||
| RUN apt update && apt install build-essential libz-dev clang procps -y |
There was a problem hiding this comment.
Note that I'm not sure if installing those dependencies in a base image is a good idea, or better left to downstream images. Even though I see the appeal of making native and native-image stuff work out of the box..
Main concern is the size
There was a problem hiding this comment.
I mean, we definitely want Scala Native to build nicely with it, so clang is a must.
I'd like to keep them, I think.
Gedochao
left a comment
Gedochao
left a comment
There was a problem hiding this comment.
@tgodzik @zielinsky can you take a look as well? I think it'd be good to have another pair of eyes on this (or two)
.github/workflows/publish-docker.yml
Outdated
| group: ${{ github.workflow }}-${{ github.ref }} | ||
| cancel-in-progress: true | ||
|
|
||
| # Configures this workflow to run every time a change is pushed to the branch called `release`. |
There was a problem hiding this comment.
...you mean like, v* tags and main, right?
| strategy: | ||
| fail-fast: true | ||
| matrix: | ||
| os: ["ubuntu-22.04", "ubuntu-22.04-arm"] |
There was a problem hiding this comment.
| os: ["ubuntu-22.04", "ubuntu-22.04-arm"] | |
| os: ["ubuntu-24.04", "ubuntu-24.04-arm"] |
we're using 24.04 everywhere in the build, I think
| retention-days: 1 | ||
|
|
||
| docker_release_merge: | ||
| runs-on: ubuntu-22.04 |
There was a problem hiding this comment.
| runs-on: ubuntu-22.04 | |
| runs-on: ubuntu-24.04 |
There was a problem hiding this comment.
I purposefully choose the lowest ubuntu version supported by GHA – linking against the newest GLIBC will mean that binaries built by this workflow won't run on Ubuntu 22.04 (at least that's the case with binaries I build with any native lang).
In mostly static/dynamic mode, native image will have the same issue: oracle/graal#6183 (comment)
| RUN ./mill -i copyTo --task 'cli[].base-image.nativeImage' --dest "./docker-out/scala-cli" 1>&2 | ||
|
|
||
| FROM debian:stable-slim | ||
| RUN apt update && apt install build-essential libz-dev clang procps -y |
There was a problem hiding this comment.
I mean, we definitely want Scala Native to build nicely with it, so clang is a must.
I'd like to keep them, I think.
Static and mostly static images are in the understanding of GraalVM, as per this doc: https://www.graalvm.org/21.3/reference-manual/native-image/StaticImages/index.html
What particular customisation for Linux x86 did you mean?
Shoot away, I'll try to answer, or at least direct you in the direction of an answer. What's there in this area was initially coded by @alexarchambault (who's also the author of |
tgodzik
left a comment
tgodzik
left a comment
There was a problem hiding this comment.
I don't know much about this, I only built basic docker images. Overall look ok as long as it work 😅
.github/workflows/publish-docker.yml
Outdated
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Log in to the Container registry | ||
| uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1 |
There was a problem hiding this comment.
This is a version from two years ago, shouldn't we bump it up to the latest one?
There was a problem hiding this comment.
Suspecting Claude might not be aware of the latest one 😅
There was a problem hiding this comment.
That's not Claude, I just copied a work flow from my project that I haven't updated in a while.
This line threw me off |
4 participants
Fixes #2132
At the moment, the scala-cli docker image is built using a combination of mill tasks, scripts, and dockerfiles that require externally built binary. What's more, it's only built for x86.
With ARM64 runners on GHA being GA, I propose a simplification - a self-contained multi-stage dockerfile, with a custom Github Workflow that merges the images into a single manifest, meaning that docker will pull the correct image no matter the target platform.
Manifest merging and pushing is a complicated step, and Docker have been amending their docs with the example, which is what this workflow is based on.
I've been using this setup in multiple apps, e.g. Mimalyzer.
There are some aspects of the build I don't really understand – static, mostly static images, customisation for Linux x86, etc.
This proposal attempts to do the simplest possible thing, so that building a docker image is just
docker build . -t VirtusLab/scala-cli.Currently, it only publishes to ghcr.io to test out the workflows without disturbing the main image on docker hub. But additional publishing steps are easily added, of course