fix: arm64 support #143
Draft
fix: arm64 support #143
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Also, as a side note: The code duplication is needed since TARGETARCH is not defined before the first FROM statement when using buildx for some reason. |
|
Seems like cross would also require major changes. It relies on containers itself so we would need to build everything outside of the Dockerfile since we can't use docker inside a docker build. |
|
Multiple runners is also not really a solution since one runner would still take almost an hour. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a working implementation for adding arm64 support.
Fixes #122
Good resources:
docker CI setup
multi-arch Dockerfile
The big issue with this is that it's extremely slow. In my testing the build time went from 3-4 min to about an hour.
I blame this mostly on the emulation done by QEMU here.
I think there are three valid implementations here:
The existing code with emulation
If a long build time is not a problem, then this might be a valid approach.
Using cross compilation
I tried to set this up with cargo but that seems to be rather difficult. Using something like cross should work, but I haven't tested this yet. While I think that would be a good solution I'm not sure if incorporating a third party tool is acceptable here.
Using multiple runners
Multiple runners as outlined here would probably work, but that would increase the complexity of the workflow significantly.
@joesturge I'm not sure if there is an optimal approach here so I'm leaving it up to you to decide, or maybe you have another idea.