WIP: feat: build the docker image for amd64 and arm64 platforms

[Dzejkop]

Motivation

Using the docker image (ghcr.io/foundry-rs/foundry) on an Apple Silicon machine runs with the following warning:

 The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

and is likely suffering slowdowns due to emulation.

Solution

This PR should build the images for both amd64 and arm64 platforms

[Dzejkop]

I'm still waiting for the workflow to pass on my repo https://github.com/Dzejkop/foundry/actions/runs/8467842044/job/23199474123

[onbjerg]

Marking this as a draft, please move it out of draft once you are ready for reviews :)

[vladislavabramov]

good lord i need this, the emulation slowdowns have been giving us so much headache lately 😅

[Sn0rt]

any update for this PR ?

@onbjerg I have try this PR undery my fork.

I found that I can't move this feature forward. because the release CI need specified runner.

more detail: https://github.com/Sn0rt/foundry/actions/runs/8999845047/job/24722880500

[peterZhang000]

When will the package succeed, my local package has been compiling for 2 hours now and it's not coming out!

[onbjerg]

@Sn0rt no update, OP has not circled back

[grandizzy]

unfortunately this approach doubles time of building, as there's a single runner building for both platforms, we'd need something like https://docs.docker.com/build/ci/github-actions/multi-platform/#distribute-build-across-multiple-runners to parallelize them

this can be tested locally by installing a registry on localhost:5000 and run the job using act (https://github.com/nektos/act)

docker run -d -p 5000:5000 --restart always --name registry registry:2
act --job release-docker

[Thegaram]

unfortunately this approach doubles time of building

Is that an issue in practice?

[grandizzy]

unfortunately this approach doubles time of building

Is that an issue in practice?

I think so, pretty sure this will kick in https://github.com/foundry-rs/foundry/blob/617931240f77e4751f04ae53e61ca855c78a5bbf/.github/workflows/docker-publish.yml#L26 (at least on my local machine took more than 2 hours)

[Thegaram]

I tried building locally like this:

docker build -t foundry-arm64 . --platform linux/arm64

It seemed to work well at first but running forge build in this image failed with (see extensive discussion in the telegram group):

"/root/.svm/0.8.24/solc-0.8.24": No such file or directory (os error 2)

It seems that simply building an image for arm64 might not always work as expected.

[stleon]

Hi @Thegaram , thank you for share your Dockerfile in telegram channel :)

In my case adding

RUN forge install foundry-rs/forge-std --no-commit --no-git

before RUN forge build resolves the problem

[sambacha]

A better way to do this would be to define a docker.hcl file like so:

# -*- hcl -*-

/** Special target: https://github.com/docker/metadata-action#bake-definition */
// docker-bake.hcl
target "docker-metadata-action" {}

target "build" {
  inherits = ["docker-metadata-action"]
  context = "./"
  dockerfile = "Dockerfile"
  platforms = [
    "linux/amd64",
    "linux/arm64"
  ]

But really, this begs the question: why even compile for docker? Why not just use the built artifacts and just package it after the fact vs. compiling for docker to begin with?

[grandizzy]

But really, this begs the question: why even compile for docker? Why not just use the built artifacts and just package it after the fact vs. compiling for docker to begin with?

That makes sense IMO

[olivmath]

Comment here to be notified when it's ready

[Dzejkop]

Sorry guys, didn't have the time to follow through with this.

But really, this begs the question: why even compile for docker? Why not just use the built artifacts and just package it after the fact vs. compiling for docker to begin with?

it's a little nicer in terms of workflow. I can just run docker build no matter the host platform (to a reasonable degree) instead of worrying about deps for the cross compilation tooling.

AFAIR the compilation time is really bad in case of arm host and x86 guest but the other way around shouldn't be so bad.

I should be able to allocate some time for this this week

[publicqi]

Do we have an update on this? Can we just use mac runner to do this?