Run CI in parallel lanes and gate desktop releases on the upgrade test

[SunkenInTime]

Problem
A CI run took about 27 minutes to go green on every PR, whatever it changed. Agents wait on it between loops, so it sets the pace of all our work.

On the latest icarus-cloud run, the Windows validate job ran every step one after another:

• Windows build: 9.0 min
• flutter test: 5.2 min
• Rust bridge tests: 3.3 min
• installer, then upgrade and rollback test: about 2 min
• everything else: about 4 min

The Linux job (13 min) ran in parallel but repeated analyze, codegen, the full test suite, and the Rust tests. Nothing cancelled a run once a newer push made it pointless: we had 140 runs in the last 7 days.

Separately, the upgrade/rollback test only ever ran in CI, against an unsigned build of a PR. release-desktop.yml never ran it, so the installer players actually download was never checked.

What changes in CI

• Always on, in parallel on Linux: analyze (plus the web binding and wall height checks), test split into 2 shards, and web (the beta's build flags).

• Lanes picked from the files a PR changes (a changes job reads gh pr diff --name-only):

  Lane	Runs when a PR changes
  convex: tsc, Convex tests, contract preview	convex/, root npm/tsconfig/vitest files
  presence-worker	presence/
  client-contract: gauntlet, codegen, drift	convex/, tool/, lib/collab/
  native-bridge: cargo tests	third_party/
  windows-build, windows-test, linux-build	lib/migrations/, *.g.dart, installer/, scripts/, the library probe test

• Every lane runs for manual runs, PRs into main, PRs that change .github/, and PRs whose file list can't be read.

• Pushes to main/icarus-cloud run every lane except the desktop ones. The release covers those, below.

• A newer push to a PR cancels its older run.

• The Windows work is two parallel jobs: windows-build (build, installer, upgrade/rollback) and windows-test (the suite on Windows).

• Rust dependencies are cached. The desktop builds cache cargokit's compiled Rust dependencies with Swatinem/rust-cache.

• One shared setup action. The Flutter setup that was copied into each job is now .github/actions/setup-flutter. Its setup-dart problem matcher is off, because it can't find its file inside a composite action.

What changes in the release

• release-desktop.yml runs Test Public Upgrade And Rollback on the signed installer, after "Verify Authenticode Signatures" and before "Stage Desktop Release".
• The test installs 3.2.3 and imports a historical .ica, then upgrades to the release and rolls back, checking the library at each step. If it fails, nothing is staged or published.
• It adds about 2 minutes to a release.

What we give up

• A PR that changes native code (windows/, linux/, third_party/), pubspec, or lib/main.dart no longer builds the desktop app before merge. A break there first shows up at release, and the release stops before publishing.
• Dart-only PRs no longer run the suite on Windows. Only one test checks the platform (hive_store_launch_test.dart).

Measured on this PR (CI changes run every lane, first run with a cold Rust cache):

	Before	After
Dart-only PR (analyze, 2 test shards, web)	~27 min	3m48s
Server PR (+ convex, client-contract)	~27 min	~3m50s (convex 1m13s, client-contract 2m24s)
Every lane	~27 min	13m38s (windows-build: 8.7 min build + 2.2 min upgrade test)

Verification

• actionlint passes on ci.yml and release-desktop.yml.
• I ran the lane script against real PRs: Tell the user when a teammate deletes the page holding their unsaved work #215 (Dart) and Wait for an upload's URL to expire before deleting its bytes #218/Sync the lineup graph to the cloud natively #196 (server) skip the desktop lane; Show who else is on a strategy and their live cursors #214/Merge main into icarus-cloud #179 (touched CI) run everything; a push runs everything except desktop.
• The previous commit's run passed every job, including the upgrade/rollback test in windows-build.
• Not verified: the release step. It only runs from main, with Azure signing, so its first real run is the next desktop release after icarus-cloud merges into main. If it's wrong, it fails before "Stage Desktop Release", so nothing bad ships.
• Known side effect: the test launches the real release build, which has the PostHog token baked in. Each release will send about two app_opened events from the CI runner to production analytics.

🤖 Generated with Claude Code

Confidence Score: 4/5

Not safe to merge until fork PRs can check contract-script changes without the repository preview key.

Findings

1.  Fork contract checks fail ▶

Summary

The PR splits CI into file-selected checks and adds an upgrade-and-rollback gate before desktop releases are staged. The latest selector change makes fork PRs that edit either Convex contract script fail the Convex check before the scripts run.

_{Reviews (2) · Last reviewed commit: "Run the Convex lane when its contract sc..."}

[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: ad053edf-f45d-4b2d-bffe-bcd832558004

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

[greptile-apps]

Comments Outside Diff

These findings sit on lines the diff does not cover, so they could not be posted inline. Each one leaves this list once its file changes.

•  Contract-script-only fork PRs fail the Convex key guard ▶

  • Bug
    • A fork pull_request into icarus-cloud changing only tool/snapshot_convex_contract.mjs or tool/audit_convex_contract.mjs now selects the Convex job. Fork PRs cannot receive the repository preview deploy key, so the job fails before running the contract scripts, regardless of their validity.
  • Cause
    • .github/workflows/ci.yml line 80 added those files to the Convex lane selector, while that lane requires CONVEX_PREVIEW_DEPLOY_KEY without a fork-safe path.
  • Fix
    • Provide a fork-safe validation path for these changes that does not require the preview key; retain secret-dependent preview deployment only for trusted runs.

[SunkenInTime]

Fixed the contract-script gap in 93ae5c0 and replied on the other three threads: they describe trade-offs the maintainer chose when the upgrade/rollback test moved into the release. @greptileai

[greptile-apps]

Fork contract checks fail

If a fork PR targeting icarus-cloud changes only tool/snapshot_convex_contract.mjs or tool/audit_convex_contract.mjs, this selector starts the Convex job. Fork PRs cannot access CONVEX_PREVIEW_DEPLOY_KEY, so the job fails at its key check before running either script, even when the changes are correct. Provide a fork-safe way to check these edits.

Artifacts

Authored fork PR workflow replay

• The Python harness extracts and executes the workflow’s selector and key guard using a synthetic file listing and empty fork-secret context, without accessing secrets.

Previous workflow skips the Convex lane

• Running the replay against d217bcf with a snapshot-script-only fork PR selected the contract lane but not Convex.

Current workflow fails the preview-key guard

• Running the same replay against HEAD selected Convex and produced exit code 1 from its key guard before contract comparison.

Routing diff and audit-script fork replay

• The executed diff shows the line 80 addition, and the audit-script-only replay shows the same key-guard failure.

_{Ran code and verified through T-Rex}

[SunkenInTime]

Pre-existing, and narrower after this PR: before it, the contract job ran on every PR, so every fork PR failed at the same key check. Now only fork PRs touching Convex or these two scripts reach it. Fork PRs are rare here (1 in the last 100), and a maintainer re-running the checks from a branch covers them, so a fork-safe path stays out of scope.

[greptile-apps]

The narrowing is a real improvement, and I agree fork PRs are uncommon. However, a maintainer re-run does not cover this case: GitHub re-runs a pull_request workflow with the privileges of the original fork-triggered run, so repository secrets remain unavailable. The Convex job will still stop at Require Convex preview deploy key before either contract script runs.

That makes this a deliberate CI policy trade-off rather than a covered path: affected fork PRs cannot get a passing required check unless the change is tested from a trusted branch or the workflow is redesigned with a fork-safe contract-check path. If fork PRs are explicitly out of scope, I’m fine treating this as accepted risk; the original concern remains technically valid.