perf(ci): cut stale runs and redundant setup

[t3dotgg]

CI was spending substantial runner time on superseded pull request commits, repeated setup, unused vendored references, and oversized workflow installs. Release and mobile workflows also paid for full checkouts and installs when they only need narrow workspace dependency closures.

This cancels stale PR CI, excludes .repos from workflow checkouts, right-sizes mobile static analysis, filters release/relay/mobile installs, removes unnecessary full-history release checkouts, and prevents unrelated label events from redeploying EAS previews. Required check names remain unchanged.

Verification:

• vp fmt --check on all six changed workflows
• workflow YAML parse and git diff --check
• sparse checkout proof in a fresh clone
• fresh filtered installs plus release smoke, desktop build, relay typecheck, and mobile typecheck
• live CI measurements on the PR
• Opus review: approved

Full audit and follow-up opportunities: https://kx1v1cubftgm.postplan.dev

Made with GPT-5.6-sol via the Codex harness in T3 Code.

---

Note

Low Risk
Workflow-only performance changes; filtered installs and sparse checkout could miss a dependency if a job’s filter is too narrow, but behavior is unchanged when filters match prior full installs.

Overview
CI workflows are tuned to spend less runner time on checkout, install, and superseded work without changing required check names.

Concurrency: ci.yml cancels in-progress runs on pull requests when new commits land. Mobile EAS preview gets per-PR concurrency with cancel-in-progress so only the latest preview build runs.

Checkout: Checkout steps across CI, deploy-relay, mobile, and release workflows use sparse checkout (/* with !/.repos/, cone mode off) so vendored .repos is not cloned. Some release jobs drop fetch-depth: 0 where full history was unnecessary (e.g. WSL node-pty and desktop build).

Install scope: run-install: true is replaced with filtered pnpm installs per job (t3code-relay..., @t3tools/mobile..., @t3tools/scripts..., desktop/CLI filters on release paths). Full monorepo install remains on main CI check/test and release preflight.

Other: Mobile native static analysis moves from 12- to 6-vCPU macOS runners. EAS preview drops unlabeled from PR types and only runs on labeled when the label is 🚀 Mobile Continuous Deployment, avoiding redeploys when unrelated labels change.

^{Reviewed by Cursor Bugbot for commit 30fcc57. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Cut stale CI runs and redundant dependency installs across workflows

• Adds top-level concurrency to ci.yml and job-level concurrency to mobile-eas-preview.yml, cancelling in-progress runs for the same PR on new pushes.
• Enables sparse checkout (excluding /.repos/) across all major workflows to reduce checkout time.
• Scopes pnpm installs to relevant workspace filters (e.g. @t3tools/mobile..., @t3tools/scripts..., t3code-relay...) instead of full installs.
• Removes unlabeled trigger from the mobile EAS preview workflow and tightens the label condition so it only fires when the exact deployment label is added.
• Downgrades the mobile_native_static_analysis runner from blacksmith-12vcpu-macos-26 to blacksmith-6vcpu-macos-26.
• Risk: Jobs in release.yml that previously used fetch-depth: 0 now use the default shallow clone depth, which may break steps that rely on full git history.

^{Macroscope summarized 30fcc57.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. 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: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a87ca5f9-e562-4887-845b-d323a4f63384

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.}

[macroscopeapp]

Approvability

Verdict: Approved

This PR contains CI/CD workflow optimizations (sparse checkouts, filtered installs, concurrency groups, runner sizing) that don't affect application runtime behavior. The flagged review comments reference pre-existing concurrency settings, not changes introduced by this PR.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate 3fa56dc

[macroscopeapp]

🟠 High workflows/mobile-eas-production.yml:33

The fixed concurrency group mobile-eas-production silently drops production dispatches. GitHub keeps at most one pending run per concurrency group even with cancel-in-progress: false, so when a build is running and two more are dispatched, the third cancels the second's pending run — a requested production build or OTA release never executes. Use a unique concurrency group per dispatch (e.g. ${{ github.run_id }}) or an external queue if every dispatch must execute.

 concurrency:
-  group: mobile-eas-production
+  group: mobile-eas-production-${{ github.run_id }}
   cancel-in-progress: false

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @.github/workflows/mobile-eas-production.yml around lines 33-35:

The fixed concurrency group `mobile-eas-production` silently drops production dispatches. GitHub keeps at most one pending run per concurrency group even with `cancel-in-progress: false`, so when a build is running and two more are dispatched, the third cancels the second's pending run — a requested production build or OTA release never executes. Use a unique concurrency group per dispatch (e.g. `${{ github.run_id }}`) or an external queue if every dispatch must execute.

[macroscopeapp]

🟡 Medium workflows/mobile-showcase-screenshots.yml:32

The fixed concurrency group mobile-showcase-screenshots causes GitHub to discard pending dispatches even though cancel-in-progress: false is set. GitHub allows only one pending run per concurrency group, so when a capture is already running and two more are dispatched, the third dispatch replaces the second pending run — the second one never executes. This silently drops requested platform/appearance captures. Use a unique key per dispatch (e.g., ${{ github.run_id }}) if every requested capture must run.

Suggested change

	group: mobile-showcase-screenshots
	group: mobile-showcase-screenshots-${{ github.run_id }}

Also found in 1 other location(s)

.github/workflows/release.yml:30

The constant concurrency group: release can silently cancel a queued release run. GitHub allows only one pending run per concurrency group and replaces an existing pending run when another is queued even with cancel-in-progress: false. Thus, if one release is running and two more scheduled/manual releases are triggered, the later trigger cancels the earlier pending release, potentially skipping a requested stable release entirely. Use a key that distinguishes releases that must be preserved, or avoid workflow concurrency for manual releases.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @.github/workflows/mobile-showcase-screenshots.yml around line 32:

The fixed concurrency group `mobile-showcase-screenshots` causes GitHub to discard pending dispatches even though `cancel-in-progress: false` is set. GitHub allows only one pending run per concurrency group, so when a capture is already running and two more are dispatched, the third dispatch replaces the second pending run — the second one never executes. This silently drops requested platform/appearance captures. Use a unique key per dispatch (e.g., `${{ github.run_id }}`) if every requested capture must run.

Also found in 1 other location(s):
- .github/workflows/release.yml:30 -- The constant concurrency `group: release` can silently cancel a queued release run. GitHub allows only one pending run per concurrency group and replaces an existing pending run when another is queued even with `cancel-in-progress: false`. Thus, if one release is running and two more scheduled/manual releases are triggered, the later trigger cancels the earlier pending release, potentially skipping a requested stable release entirely. Use a key that distinguishes releases that must be preserved, or avoid workflow concurrency for manual releases.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 45ea4ad. Configure here.}