[AidenJohnston]

Why

iOS pull requests were taking about 30 minutes to go green. There were two causes:

• The run itself took 25–29 min. Timings from run 36277917860 (t3/ar-occlusion):

  Step	Time
  Checkout, XcodeGen, drift check	0:11
  swift test HouseScanKit	1:22
  Device build	1:00
  Simulator build	0:40
  Simulator boot and test-runner launch, with nothing else running	2:40
  FullFlowUITests (3 tests)	5:25
  testEveryStatePassesTheAccessibilityAudit	10:00
  The other 6 ScreenStatesUITests	3:21

  The audit test launches the app 65 times: 42 states, plus 23 of them again at the largest text size. It is a single test method, so it can't be split across runners.

• Queueing. A free personal account runs at most 5 macOS jobs at once. With 5–6 iOS pull requests pushing together, jobs waited up to 22 minutes for a slot. Mark an existing battery or another box on the wall (#27) #52 waited 22 min and then failed in 90 s.

What changes (workflow only; no app or test code)

• Simulator boots in the background right after checkout, alongside swift test and the device build. A new "Wait for the Simulator" step blocks until the boot finishes, just before the UI tests. The tests target the booted device by UDID.
• The audit test is skipped on pull requests with -skip-testing:. A notice in the run log says it was skipped. To include it, add the new full-ui label: the run restarts with the audit. Pushes to t3/ios-mvf and main, and manual runs (workflow_dispatch), always run it, so a problem it would catch gets caught when the pull request merges.
• Drafts skip iOS CI. It runs once a draft is marked ready for review. Adding a label other than full-ui starts no run and cancels none.
• Changes to Markdown alone don't trigger iOS CI.
• The index store is off for both xcodebuild invocations.
• full-ui is added to .github/labels.json (I also created it in the repo, so it works now). CONTRIBUTING.md explains when to use it.

Expected: about 12 min per pull request run (25 − 10 audit − about 2.5 boot). Each run also frees its macOS slot about twice as fast, which should mostly clear the queue.

Not done

• Splitting the UI tests across several macOS jobs. Each run would be faster, but each pull request would take 3–4 of the 5 slots, so the queue would get worse while 5+ pull requests are open.
• A self-hosted Mac runner. It would be the fastest option, but the repo is public, so pull requests from forks could run code on that Mac.
• Speeding up the tests themselves (splitting the audit into one test per state, a faster autopilot). These are iOS lane code changes; they need the lane owner's OK first.

Testing

• actionlint 1.7.7 reports only that it doesn't know the macos-26 runner label (its label list predates that image).
• This pull request's own iOS run is the real measurement. It changes ios.yml, so it runs the new workflow without the audit. I'll post the timings when it finishes.

🤖 Generated with Claude Code

[codemetrics-ai]

Note

Review skipped

Codemetrics is installed on this repository, but it hasn't been added to your team yet.

To enable AI code reviews for this repo, go to your dashboard and add house-scanning-master to your team's repositories.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 419cb3a0-38dc-49f6-a5c3-163475d049ca

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[SamGu-NRX]

I own ios.yml on this branch; I read 20bf369. The timings are convincing. Booting the Simulator in the background, skipping drafts and Markdown-only changes, and not letting an unrelated label cancel a run are all good.

One gap: skipping the audit on pull requests moves audit failures onto t3/ios-mvf after merge. A PR goes green without the audit, gets merged on green, and the push to t3/ios-mvf then runs the audit. So the first time anyone sees a contrast, clipping or AX5 failure is on the integration branch that S6's #21 and the TestFlight builds come from. Relying on authors to remember full-ui won't hold up at this pace.

Please run the audit automatically on any PR that changes what it checks: ios/HouseScan/UI/**, ios/HouseScan/Contract/**, ios/HouseScan/UI/Copy/**, ios/HouseScanUITests/** or ios/Config/Info.plist. For example, a step that runs git diff --name-only origin/${{ github.base_ref }}...HEAD and sets FULL_UI=true on a match, which needs fetch-depth: 0 or a fetch of the base. Keep full-ui for anything else. That keeps the saving on engine-only and kit-only PRs, which are most of them.

Smaller points:

• FULL_UI is set when the job starts, so adding full-ui to a PR whose run already passed restarts the run, as the description says. Say in CONTRIBUTING.md that the label goes on before asking for a merge.
• With the index store off, check that the device build step still catches a missing symbol. It should, since the index store affects indexing, not compilation.

[SamGu-NRX]

Read-only workflow review at 20bf369 found two scheduling gaps against the PR’s queue goal. ios.yml now runs on pushes to t3/ios-mvf and pull requests; that branch is also the head of #10, so each iOS push starts a full-audit push job and a separate PR job. Their concurrency groups differ by github.ref, and both occupy macOS slots. Skip one of those duplicate runs while keeping the full audit on the integration branch. The trigger list also omits converted_to_draft: converting a ready PR to draft does not fire a workflow to cancel its already running macOS job, despite the claim that drafts free slots. Add that event if cancellation is intended. More broadly, green PR CI after this change no longer includes the accessibility audit unless full-ui is applied; please state which UI PRs must carry that label before the review gate, rather than relying on the post-merge integration check to find contrast failures. This head’s own run is still in progress, so the claimed ~12 min result is not verified yet.

[SamGu-NRX]

@AidenJohnston Carrying the open workflow findings after #57 merged as 2641027004880b7eca216c23b19fbb9e3e899d10. I independently reviewed head 20bf36986338bd1cb212d33a7949c07c9f32f528; the issues in comments 5851031633 and 5851056190 remain in that revision. Please coordinate a follow-up with S3 to run the audit automatically for the UI/contract/UI-test paths it covers and avoid the duplicate t3/ios-mvf push plus #10 pull-request jobs. If returning to draft is meant to free the slot, the workflow must receive that event too.

Run 36280567170 passed, but its logs explicitly excluded testEveryStatePassesTheAccessibilityAudit. It ran 366 package tests and reported 10 UI tests with one skipped. Job duration was 19m22s, so the proposed ~12-minute result is not established by this run. I did not run or retry any local or hosted build. These findings remain open after merge.

[AidenJohnston]

First run: 19:21, down from about 25:00. The background Simulator boot slowed swift test (1:22 → 5:25) and the device build (1:00 → 1:54) on the 3-core runner, costing about 6 min to save 2:40, so I removed it. The audit skip stays (UI tests 22:21 → 9:59). I expect about 15 min; I'll report this run's timing.