Github now provides custom runners for us to use with more CPU,
memory, and disk, so we are switching from the default runners
to 8 core runners for Linux and Windows. This change also allows
us to consolidate jobs now that we have runners with more disk space.
Details
- Reviewers
asl
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comments below are totally unrelated to this patch, I'm just curious.
.github/workflows/clang-tests.yml | ||
---|---|---|
12–17 | What's the reason to include pull_request here if all pull requests are automatically closed? | |
.github/workflows/llvm-project-tests.yml | ||
39–45 | Did you consider using sccache here? I see that right now this job takes ~4 hours, and the majority of time is spent on builds, which correlates with my experience building llvm in github actions. Enabling sccache should bring that down to ~3-15 minutes (windows is still much slower than linux, but that's a big improvement over a few hours). |
.github/workflows/clang-tests.yml | ||
---|---|---|
12–17 | This patch is for the release branch where we use pull requests for pre-commit testing. We put the pull requests in the llvm/llvm-project-release-prs repo to keep them separate, so they aren't automatically closed. | |
.github/workflows/llvm-project-tests.yml | ||
39–45 | Is sccache something that is integrated with GitHub or do we have to set up our own server somewhere? With these new runners, most jobs take around 30 minutes which is a big improvement over the old runners. Here is an example pull requests that uses the new runners: https://github.com/llvm/llvm-project-release-prs/pull/1 |
.github/workflows/clang-tests.yml | ||
---|---|---|
12–17 | Oh, I see, makes sense then. | |
.github/workflows/llvm-project-tests.yml | ||
39–45 | That’s a fantastic improvement. But builds are still 39 minutes long. For github-hosted machines I’ve had success with github.com/actions/cache (see for example https://github.com/intel/llvm/commit/95104c079bacd4dd2920c8439d97d3f93e601b18). In my config llvm produced ~1,5 gigs of binaries. 10 gigs cache was more than enough for that task. On self-hosted machines that’s even easier. You can persist data on the machine itself: https://github.com/intel/llvm/blob/f6420c769d473c00be736b8df361e10dd98a6009/.github/workflows/sycl_windows_build_and_test.yml#L32 |
.github/workflows/llvm-project-tests.yml | ||
---|---|---|
39–45 | Thanks for this information. I will look into enabling this in a follow-up patch. |
.github/workflows/libclang-abi-tests.yml | ||
---|---|---|
78 | I created generic labels for the machines, so we can change the machine types without updating the workflow definition. |
.github/workflows/libclang-abi-tests.yml | ||
---|---|---|
78 | I just checked and it looks like the labels are gone now. It says that unassigned labels will be removed periodically, so maybe they were removed, because we weren't using them? I can add them back after I commit the patch, or if you think it's better, we can just use the labels provided by github. |
.github/workflows/clang-tests.yml | ||
---|---|---|
3 | I'd probably suggest to ignore forks here as well. And allow manual triggering |
.github/workflows/llvm-project-tests.yml | ||
---|---|---|
39–45 | There is also hendrikmuhs/ccache-action which specializes the cache action for ccache/sccache. It's also of interest to cache the ThinLTO cache. The cache sizes need to be tuned a bit since GH limits the total size. |
This is on hold, until we figure out if GitHub will charge us from the custom runners.
I'd probably suggest to ignore forks here as well. And allow manual triggering