ci: only enforce Sparkle monotonic check on release

[austinywang]

Summary

• remove the Sparkle monotonic guard from the CI workflow guard job
• run the existing Sparkle monotonic script early in the release workflow right after checkout
• fail releases before expensive build/sign work when the published Sparkle build is newer or equal

---

Summary by cubic

Only enforce Sparkle build-number monotonicity during releases. Run the check pre-tag via ./scripts/release-pretag-guard.sh and first in release.yml to fail fast before build/sign.

• Refactors
  • Remove the check from ci.yml; use the shared ./tests/test_ci_sparkle_build_monotonic.sh in release.yml and the new pre-tag guard script.
  • Delete inline Sparkle version parsing in release.yml and update release docs/commands to require the pre-tag guard before tagging.

^{Written for commit 05eff80. Summary will update on new commits.}

Summary by CodeRabbit

• Chores
  • Reorganized build validation checks in the release pipeline by consolidating the Sparkle build number validation into the release workflow for improved streamlining.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
cmux	Ready	Preview, Comment	Apr 6, 2026 10:53pm

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: a6e86a3a-3180-433a-ba83-a3fc956c3e67

📥 Commits

Reviewing files that changed from the base of the PR and between 179b16c and 7d39bee.

📒 Files selected for processing (2)

• .github/workflows/ci.yml
• .github/workflows/release.yml

💤 Files with no reviewable changes (1)

• .github/workflows/ci.yml

---

📝 Walkthrough

Walkthrough

The changes relocate a Sparkle build number monotonicity validation step from the ci.yml workflow's guard-tests job to the release.yml workflow's build-sign-notarize job, replacing a conditional inline shell command with an unconditional dedicated script invocation.

Changes

Cohort / File(s)	Summary
Sparkle Build Validation Workflow Restructuring .github/workflows/ci.yml, .github/workflows/release.yml	Removed Sparkle monotonicity check from ci.yml's workflow-guard-tests job; added unconditional dedicated script invocation in release.yml's build-sign-notarize job, replacing the previous conditional inline shell step that parsed build version and validated against published appcast.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• Fix Sparkle update path: bump build number + add monotonic guard #2625: Addresses the same Sparkle build-number monotonicity validation logic—the referenced PR introduces the script and guard steps while this PR restructures their execution across workflows.
• Publish separate universal nightly track #1067: Modifies CI/workflow logic and handles Sparkle appcast generation and validation, sharing the same validation component domain.

Suggested labels

codex

Poem

🐰 A Sparkle check hops from guard to release,
From conditional chains to unconditional peace,
The script takes the stage, inline steps depart,
Monotonic builds bloom—a refactored art! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	Description covers the what and why, but lacks testing details and verification steps required by the template.	Add a Testing section explaining how the changes were verified, and confirm requested bot reviews per the repository template.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately reflects the main change: moving Sparkle monotonic validation from general CI to release-only enforcement.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat-sparkle-monotonic-release-only

---

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 and usage tips.}

[cubic-dev-ai]

This review could not be run because your cubic account has exceeded the monthly review limit. If you need help restoring access, please contact contact@cubic.dev.

[greptile-apps]

Greptile Summary

This PR moves the Sparkle build-number monotonic check out of CI's workflow-guard-tests job and into the release workflow as an early gate, so invalid build numbers fail fast before expensive build/sign/notarize work.

• Ordering issue in release.yml: the Sparkle check runs unconditionally before guard_release_assets, so any workflow_dispatch re-run on an already-published tag hard-fails (local == published) before reaching the guard that sets skip_all=true and exits gracefully. The fix is to move the step after the guard and condition it on steps.guard_release_assets.outputs.skip_all != 'true'.

Confidence Score: 4/5

Safe for net-new releases; re-runs on already-published tags will hard-fail at the Sparkle check before reaching the idempotency guard

One P1 ordering bug: Sparkle check precedes guard_release_assets, breaking the re-run safety contract — score is 4 rather than 5

.github/workflows/release.yml — step ordering of Sparkle check relative to guard_release_assets

Important Files Changed

Filename	Overview
.github/workflows/release.yml	Adds Sparkle monotonic check early in release job, but the check precedes the idempotency guard, breaking graceful re-runs on already-published tags
.github/workflows/ci.yml	Removes the Sparkle monotonic check from workflow-guard-tests job; no other changes to CI

Sequence Diagram

sequenceDiagram
    participant GH as GitHub Actions
    participant Runner as macOS Runner

    GH->>Runner: Checkout (submodules: recursive)
    Runner-->>GH: source ready

    Note over Runner: ⚠️ always runs — no guard condition
    GH->>Runner: Validate Sparkle build number is monotonic
    Runner-->>GH: local > published? FAIL if local == published

    GH->>Runner: Guard immutable release assets
    Runner-->>GH: sets skip_all output

    alt skip_all == 'true' — already published
        Note over GH,Runner: Would skip remaining steps, but Sparkle check already failed above
    else skip_all != 'true'
        GH->>Runner: Select Xcode + Install build deps
        GH->>Runner: Build universal app (Release)
        GH->>Runner: Codesign + Notarize
        GH->>Runner: Generate Sparkle appcast
        GH->>Runner: Upload release asset + R2 appcast
    end

    GH->>Runner: Cleanup keychain (always)

Loading

_{Reviews (1): Last reviewed commit: "ci: only enforce Sparkle monotonic check..." | Re-trigger Greptile}

[greptile-apps]

Sparkle check runs before the idempotency guard

The Sparkle check is placed before guard_release_assets, so a workflow_dispatch re-run on an already-fully-published tag will hard-fail here — the local build number equals the published appcast's build number (X <= X), triggering exit 1 — before the guard can run to set skip_all=true and exit gracefully. The guard exists specifically to make the release workflow safe to re-run; placing the Sparkle check first inverts that contract.

Move the step to after guard_release_assets and add the guard condition:

Suggested change

	- name: Validate Sparkle build number is monotonic
	run: ./tests/test_ci_sparkle_build_monotonic.sh
	- name: Validate Sparkle build number is monotonic
	if: steps.guard_release_assets.outputs.skip_all != 'true'
	run: ./tests/test_ci_sparkle_build_monotonic.sh

This requires reordering so guard_release_assets runs first.