Multi-architecture Linux & macOS builds #44
Draft
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.
Context
I'm working on a CI build matrix for a project. For it I need:
Since qemu builds on macOS arm hardware doesn't quite work, I'm running all intel builds on a macOS intel host and all arm builds on a macOS arm host.
I'm pleased to say that I have that working with the changes in this PR.
Changes
For this PR, I've done a few things to the Ubuntu docker image:
Named layers so the
test
wouldn't leave files in the image.The test runs, but it's not included in the production image.
Removed the
ARCH
variable so that it can detect the architecture and install the appropriate version of CMAKE.This means I can build arm64 macOS and Ubuntu images on an M2 Mac.
It also means I can build x86_64 macOS and Ubuntu images on an Intel Mac.
This does not fix the QEMU jmalloc issue at tamatebako/tebako#229
Sets a
TEBAKO_RUBY_VERSION
variable in the contianerThis is needed because
ARG
can't persist across layers.Consequences
This should drop-in to the current CI images; however the removal of the
ARCH
that was hard coded means it might need to be moved into theyaml
files for the runner if an override is needed for any reason (it shouldn't).Considerations
I think the
tebako press
CLI should run via ENV vars. I setTEBAKO_RUBY_VERSION=3.3.6
, so this should be possible and it should run:That means I could set the
TEBAKO_RUBY_VERSION
in the container and it would run the pre-installed version without the user specifying anything. This might also mean if tebako wants to maintain an image repository for prebuilt compilers, they'd have to start maintaining versions likeubuntu-ruby:3.3.6
, etc.