Switch some workflows to use container: instead of docker_run.sh.
#18252
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
ScottTodd
added
infrastructure
ScottTodd
commented
Aug 16, 2024
| @@ -28,13 +28,14 @@ concurrency: | |||
| jobs: | |||
| linux_x64_clang_byollvm: | |||
| runs-on: ubuntu-20.04 | |||
| container: gcr.io/iree-oss/base@sha256:dc314b4fe30fc1315742512891357bffed4d1b62ffcb46258b1e0761c737b446 | |||
There was a problem hiding this comment.
I have similar changes planned for workflows like https://github.com/iree-org/iree/blob/main/.github/workflows/ci_linux_x64_clang_tsan.yml, but those aren't as simple... something about docker_run.sh seems to be load bearing there when it shouldn't be.
marbre
approved these changes
Aug 16, 2024
Yeah I can just wait the 4 hours until the jobs on this PR finish before merging. |
|
I think it is fair to be confident enough that it will pass :) |
ScottTodd
added a commit
that referenced
this pull request
Aug 19, 2024
Progress on #15332 and #18238 . Similar to #18252, this drops a dependency on the [`build_tools/docker/docker_run.sh`](https://github.com/iree-org/iree/blob/main/build_tools/docker/docker_run.sh) script. Unlike that PR, this goes a step further and also stops using [`build_tools/cmake/build_all.sh`](https://github.com/iree-org/iree/blob/main/build_tools/cmake/build_all.sh). Functional changes: * No more building `iree-test-deps` * We only get marginal value out of compiling test files using a debug compiler * Those tests are on the path to being moved to https://github.com/iree-org/iree-test-suites * No more ccache * The debug build cache is too large for a local / GitHub Actions cache * I want to limit our reliance on the remote cache at `http://storage.googleapis.com/iree-sccache/ccache` (which uses GCP for storage and needs GCP auth) * Experiments show that this build is not significantly faster when using a cache, or at least dropping `iree-test-deps` provides equivalent time savings Logs before: https://github.com/iree-org/iree/actions/runs/10417779910/job/28864909582 (96% cache hits, 9 minute build but 19 minutes total, due to `iree-test-deps`) Logs after: https://github.com/iree-org/iree/actions/runs/10423409599/job/28870060781?pr=18255 (no cache, 11 minute build) ci-exactly: linux_x64_clang_debug --------- Co-authored-by: Marius Brehler <[email protected]>
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.
Progress on #15332 and #18238 .
The
build_tools/docker/docker_run.shscript does a bunch of weird/hacky setup, including setup forgcloud(for working with GCP) and Bazel-specific Docker workarounds. Most CMake builds can just use a container for the entire workflow (https://docs.github.com/en/actions/writing-workflows/choosing-where-your-workflow-runs/running-jobs-in-a-container). Note that GitHub in its infinite wisdom changed the default shell just for jobs that run in a container, frombashtosh, so we flip it back.These jobs run nightly on GitHub-hosted runners, so I tested here:
(Those jobs should also run on this PR, but they'll take a while)
skip-ci: no impact on other workflows