-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: feat: build the docker image for amd64 and arm64 platforms #7512
base: master
Are you sure you want to change the base?
Conversation
I'm still waiting for the workflow to pass on my repo https://github.com/Dzejkop/foundry/actions/runs/8467842044/job/23199474123 |
Marking this as a draft, please move it out of draft once you are ready for reviews :) |
good lord i need this, the emulation slowdowns have been giving us so much headache lately 😅 |
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 more detail: https://github.com/Sn0rt/foundry/actions/runs/8999845047/job/24722880500 |
When will the package succeed, my local package has been compiling for 2 hours now and it's not coming out! |
@Sn0rt no update, OP has not circled back |
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
|
Is that an issue in practice? |
I think so, pretty sure this will kick in
|
I tried building locally like this: docker build -t foundry-arm64 . --platform linux/arm64 It seemed to work well at first but running
It seems that simply building an image for arm64 might not always work as expected. |
Hi @Thegaram , In my case adding
before |
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? |
That makes sense IMO |
Comment here to be notified when it's ready |
Sorry guys, didn't have the time to follow through with this.
it's a little nicer in terms of workflow. I can just run 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 |
Do we have an update on this? Can we just use mac runner to do this? |
Small update from me:
I'm now looking into building in CircleCi since they seem to support arm64 runners. I am struggling with a weird bug that prevents my arm64 job from starting, I'm currently waiting for CircleCi support to get back to me on this |
@Dzejkop maybe I am missing something, but have you considered simply using Lines 120 to 138 in a3071e5
|
@grandizzy I haven't though of that! it's an option, I'll look into it if CircleCI route doesn't pay off. It does make docker images dependent on foundry build runs from the past. And it also means that if, e.g. you want to fork foundry or experiment with some custom functionality - you'd have to switch up the urls, or setup your own CI to build artifacts. With a from the source build it "just works". |
Motivation
Closes #8039
Using the docker image (ghcr.io/foundry-rs/foundry) on an Apple Silicon machine runs with the following warning:
and is likely suffering slowdowns due to emulation.
Solution
This PR should build the images for both amd64 and arm64 platforms