Originally created by: Akarsh-Hegde
Rebuilds release-staging.yml so the two macOS architectures compile concurrently on separate runners instead of one after the other, and wires publishing onto that structure.
Measured on the prototype: 29 min against a ~43 min baseline (run 29723988701).
release-staging.yml handed the whole job to semantic-release, whose prepareCmd is what compiles — and that is precisely the part that cannot be parallelised. So the phases are pulled apart:
| job | does |
|---|---|
plan |
semantic-release --dry-run decides the version — no tag, no release, no prepareCmd. Pins the SHA. |
build (matrix) |
both arches compile that version, concurrently, via tauri build --no-bundle |
release |
lipo → sign → bundle → notarize → package → verify as explicit steps, then semantic-release as a publisher only |
windows-release |
unchanged; Windows was never part of the macOS build arm |
.releaserc.staging.json loses its prepareCmd entirely and keeps publishCmd — everything prepareCmd did is on disk by the time semantic-release runs. The seam that makes this possible: tauri bundle packages without re-invoking cargo.
Splitting the phases means the version is computed twice, once per semantic-release invocation. They can diverge if a v* or v*-staging* tag lands in between — a concurrent production release.yml run can do exactly that, since it sits in a different concurrency group.
Publishing then would ship artifacts stamped with a different version than the tag the updater compares against: a silently broken update. "Assert the version has not moved" re-runs the dry-run and fails rather than publish. A failure costs only a re-run.
None was visible in the build-only prototype, because none of them affects whether a build succeeds:
cargo clean -p tauri-plugin-notifications --release was absent from the build jobs. rust-cache restores target/ (fingerprint reads fresh) but not registry/src, where the pinned 0.4.6 fork's build.rs writes its Swift static lib — build script skipped, .a gone, link fails. --release is load-bearing; without it the clean hits the debug profile and reports "Removed 0 files".notarize-dmg.sh was absent. tauri bundle notarizes and staples the .app but only signs the DMG — a ticket is keyed to the cdhash of what was submitted, so the stapled app inside does not cover its container. Users would have hit "can't check it for malicious software".package-updater.sh was absent. Besides writing latest.json from the real minisign signature, it is the only thing that reads tray/minimum-version and stamps Minimum-Version: into the manifest notes — the forced-update floor would have silently stopped shipping.The first commit added this as a second file (release-staging-parallel.yml) to run beside the old one during a proving period. That's dropped: two near-identical workflows with the Windows job duplicated verbatim is a drift hazard, and the fallback it preserved is a git revert away regardless. The restructure now lands in release-staging.yml itself, on the unchanged [staging-release] marker.
permissions: contents → write; the release job checks out at the pinned SHA with fetch-depth: 0 + fetch-tags, so the tag lands on the exact commit the binaries were built from.
save-if: false stays on rust-cache. Two per-arch target/ caches would add ~4GB to a repo already at its 10GB quota (see [#488], merged specifically to get back under it) and would evict release.yml's cache. Worth revisiting once the quota has headroom — it is the remaining easy win on top of the split.
release.yml (production) is untouched and still sequential. Porting the same restructure there is a follow-up, gated on this path cutting a real prerelease that an installed staging app auto-updates to.
plan → build (×2) → release → windows-release[staging-release] marker commit; confirm it cuts a prerelease and moves updater-staginglatest.json carries both darwin-* keys, the windows-x86_64 key, and the Minimum-Version: line🤖 Generated with Claude Code
Originally posted by: coderabbitai[bot]
✨ Finishing Touches
🧪 Generate unit tests (beta)
- [ ] Create PR with unit tests - [ ] Commit unit tests in branch `ci/parallel-staging-publish`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](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai) - [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai) - [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai) - [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code)Comment
@coderabbitai helpto get the list of available commands.Ticket changed by: Akarsh-Hegde