Repository navigation
feat: make iOS runs on small CI runners reliable and explain host starvation - #295
Merged
Merged
Conversation
…nners - snapshot the busiest processes by CPU and RSS at session start - warn (with a GitHub annotation) when the CI runner is saturated before startup - attach peak load, min free memory and swapouts to PlatformReadyTimeoutError - defer the Metro prewarm until the simulator is booted on small hosts - e2e: disable Spotlight, drop watchman, pre-boot the simulator after Xcode setup
… hosted runners Moves the simulator slimming from this repo's workflow into the GitHub Action, through a new `harness ci prepare-ios-simulator` command, so projects using the action get it too. It restores the full list of 57 services: the 11 cheapest-to-stop services left the runner as starved as before.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…ation - Warn about a saturated runner when idle CPU is below 5%, not on a lagging load average; blame a starved host on a timeout only for low mean idle CPU or swapping, not for the load a simulator boot causes. - Give the prepare step an overall deadline, wait for a booting simulator before slimming it, and escape its warnings. - Warn on an unknown slimIosSimulator value and skip Spotlight when it is false.
…the GitHub Action Harness keeps booting the simulator itself, as before. After boot (and the settle step), on CI hosts with 3 cores or less than 8 GB, it stops the simulator's unused background services before installing the app. The slimOnCI option of appleSimulator() overrides the host check. The action step, its input and the `harness ci prepare-ios-simulator` command are removed.
This branch was successfully deployed
This file contains hidden or 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
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.
What is this?
iOS e2e jobs on the standard GitHub macOS runner (3 cores, 7 GB) failed at random. The simulator took 8–10 minutes to become ready, or Harness gave up at the 600s startup timeout, and nothing said why. This change makes those runs reliable for every project that runs Harness on small CI runners, and makes the cause visible when a run still struggles.
How does it work?
PlatformReadyTimeoutErrorreports the peak load, average idle CPU, minimum free memory and swapped-out memory. If the CPU was almost never idle or memory was swapped out, it says the host was starved instead of suggesting a larger timeout.slimOnCIoption ofappleSimulator()forces it on or off; Harness never does this outside CI.Why is this useful?
Measured on this repo's iOS e2e job:
Projects on standard GitHub macOS runners stop hitting platform-ready timeouts without having to change anything, whether or not they use the GitHub Action. When a run is still slow, the warning and the error message name the host as the cause, instead of leaving it a mystery.