Darwin CI: use macos-13 runners and other tweaks #32748
Merged
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
pullapprove
bot
requested review from
andy31415,
andyg-apple,
anush-apple,
arkq,
bzbarsky-apple,
carol-apple,
cecille,
chrisdecenzo,
chshu,
chulspro,
cliffamzn,
Damian-Nordic,
dhrishi,
harimau-qirex,
harsha-rajendran,
hawk248,
hicklin,
jepenven-silabs,
jmartinez-silabs,
jmeg-sfy,
joonhaengHeo,
jtung-apple,
kkasperczyk-no,
kpschoedel,
lazarkov,
lpbeliveau-silabs,
LuDuda and
mhazley
ksperling-apple
force-pushed
the
darwin-ci-macos-13
branch
5 times, most recently
from
726e8be to
7a206fa
Compare
|
PR #32748: Size comparison from ef01670 to 7a206fa Decreases (1 build for efr32)
Full report (72 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, stm32, telink)
|
ksperling-apple
force-pushed
the
darwin-ci-macos-13
branch
from
08f4af8 to
21a2ff6
Compare
|
PR #32748: Size comparison from 4e582fc to 21a2ff6 Full report (38 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, k32w, linux, mbed, nrfconnect, psoc6, qpg, stm32)
|
ksperling-apple
force-pushed
the
darwin-ci-macos-13
branch
4 times, most recently
from
6b1b915 to
3ccacf1
Compare
|
PR #32748: Size comparison from 4e582fc to 3ccacf1 Full report (40 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, stm32)
|
ksperling-apple
force-pushed
the
darwin-ci-macos-13
branch
2 times, most recently
from
3823472 to
9c9703b
Compare
According to github docs these have 4 CPUs (vs 3 for macos-12 == latest). In practice compile steps seem to be about 7% faster. Also use the pre-installed Python (3.12), remove the "aggregation" step, and run crash log collection after failure (not success), and condense disk space output to large directories only.
This avoids caching a corrupted cache in cases where a job modifies the environment (e.g. the Darwin job hiding zap-cli). It also makes the cache available slightly sooner. Also add plumbing for splitting caches over buildjet and github backends.
ksperling-apple
force-pushed
the
darwin-ci-macos-13
branch
from
9c9703b to
fecc7af
Compare
|
PR #32748: Size comparison from 4e582fc to fecc7af Decreases (1 build for efr32)
Full report (72 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, stm32, telink)
|
|
PR #32748: Size comparison from 4e582fc to f5cd6cc Decreases (1 build for efr32)
Full report (72 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, stm32, telink)
|
arkq
approved these changes
Mar 28, 2024
andy31415
approved these changes
Mar 28, 2024
andy31415
reviewed
Mar 28, 2024
|
|
||
| tests: | ||
| name: Run framework tests | ||
| if: github.actor != 'restyled-io[bot]' | ||
| runs-on: macos-latest | ||
| needs: [ framework ] # serialize to avoid running to many parallel macos runners |
| @@ -134,24 +131,15 @@ jobs: | |||
| tv-casting-bridge: | |||
| name: Build TV Casting Bridge example | |||
| if: github.actor != 'restyled-io[bot]' | |||
| runs-on: macos-latest | |||
| needs: [ framework ] # serialize to avoid running to many parallel macos runners | |||
| - uses: Wandalen/[email protected] | ||
| name: Bootstrap from cache | ||
| id: bootstrap-cache | ||
| # Split caches across backends |
There was a problem hiding this comment.
This could use comments explaining why we are doing that. Because I don't understand why we're doing that.
|
|
||
| tests: | ||
| name: Run framework tests | ||
| if: github.actor != 'restyled-io[bot]' | ||
| runs-on: macos-latest | ||
| needs: [ framework ] # serialize to avoid running to many parallel macos runners |
There was a problem hiding this comment.
Does this really help things? My mental model is that each job that runs in a separate runner has some fixed overhead (checkout, bootstrap) plus whatever work it actually needs to do. Serializing things but still using separate runners does not remove any of the fixed overhead, right?
So it increases latency to completion for a single PR, probably does not decrease latency to completion when multiple PRs need jobs run in parallel. Might reduce latency to error detection when multiple PRs are run in parallel.
Again, if there is a benefit here that I am missing, maybe the comments could more clearly talk about the tradeoffs and why we are making this one?
There was a problem hiding this comment.
This is somewhat experimental... will see if this makes the overall queueing behavior worse or better.
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.
According to github docs these have 4 CPUs (vs 3 for macos-12 == latest). In practice compile steps seem to be about 7% faster.
Also use the pre-installed Python (3.12), remove the "aggregation" step, and run crash log collection after failure (not success).
Tweak bootstrap caching to save the cache right after bootstrap, so it doesn't matter if the build makes changes to the environment (like messing with zap-cli). Also allow us to split caches between GitHub and BuildJet (GitHub provides insight into what is actually cached but only 10G of storage).