Install QEMU emulator in arm64 variant of cpubuilder image. #13
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
marbre
approved these changes
Sep 20, 2024
| ######## target-architecture-specific installs ######## | ||
| WORKDIR /install-target-arch | ||
| COPY build_tools/install_arch_extras_${TARGETARCH}.sh ./ | ||
| RUN ./install_arch_extras_${TARGETARCH}.sh && rm -rf /install-target-arch |
There was a problem hiding this comment.
What about eventually going with something like
Suggested change
| RUN ./install_arch_extras_${TARGETARCH}.sh && rm -rf /install-target-arch | |
| RUN if [[ "${TARGETARCH}" = "arm64" ]] ; then ./install_arch_extras_arm64.sh && rm -rf /install-target-arch ; fi |
But honestly I don't know if I like this either and the empty bash script could be the better way.
There was a problem hiding this comment.
Yeah I looked at other patterns and this looked cleanest in the .Dockerfile. I don't really mind carrying around empty scripts as long as there are only a few of them.
ScottTodd
added a commit
to iree-org/iree
that referenced
this pull request
Sep 23, 2024
Progress on #15332. This was the last active use of [`build_tools/docker/`](https://github.com/iree-org/iree/tree/main/build_tools/docker), so we can now delete that directory: #18566. This uses the same "cpubuilder" dockerfile as the x86_64 builds, which is now built for multiple architectures thanks to iree-org/base-docker-images#11. As before, we install a qemu binary in the dockerfile, this time using the approach in iree-org/base-docker-images#13 instead of a forked dockerfile. Prior PRs for context: * #14372 * #16331 Build time varies pretty wildly depending on cache hit rate and the phase of the moon: | Scenario | Cache hit rate | Time | Logs | | -- | -- | -- | -- | Cold cache | 0% | 1h45m | [Logs](https://github.com/iree-org/iree/actions/runs/10962049593/job/30440393279) Warm (?) cache | 61% | 48m | [Logs](https://github.com/iree-org/iree/actions/runs/10963546631/job/30445257323) Warm (hot?) cache | 98% | 16m | [Logs](https://github.com/iree-org/iree/actions/runs/10964289304/job/30447618503?pr=18569) CI history (https://github.com/iree-org/iree/actions/workflows/ci_linux_arm64_clang.yml?query=branch%3Amain) shows that regular 97% cache hit rates and 17 minute job times are possible. I'm not sure why one test run only got 61% cache hits. This job only runs nightly, so that's not a super high priority to investigate and fix. If we migrate the arm64 runner off of GCP (#18238) we can further simplify this workflow by dropping its reliance on `gcloud auth application-default print-access-token` and the `docker_run.sh` script. Other workflows are now using `source setup_sccache.sh` and some other code.
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.
Follow-up to #11.
This emulator was originally installed in iree-org/iree#16331. We've been carrying it around since then.
I'm not thrilled with the file sitting in a cloud storage bucket (GCS or Azure). The file is 5MB so maybe we could check it in here via git LFS? Or we could build it from source via our automation.