feat: add desktop binary build to staging deploy

[FSM1]

Summary

• Adds a build-desktop job to deploy-staging.yml that builds a macOS .dmg via tauri-apps/tauri-action and uploads it to a GitHub pre-release
• Runs in parallel with existing build jobs — desktop build failure cannot block VPS deployment
• Installs macFUSE headers for fuser compilation, bakes staging env vars into the binary

Test plan

• Push a v*-staging-rc-* tag and verify the build-desktop job starts on a macOS runner
• Verify the .dmg appears on the GitHub Release page as a pre-release
• Download and launch the .dmg (right-click > Open to bypass Gatekeeper)
• Verify existing deploy-vps job completes independently of desktop build

🤖 Generated with Claude Code

Summary by CodeRabbit

• Chores
  • Added automated desktop application builds to the staging release pipeline. macOS desktop binaries (.dmg files) are now generated and published as pre-release artifacts for staging releases, with staging-specific configurations included.

[coderabbitai]

Walkthrough

A new GitHub Actions workflow job "Build Desktop App (macOS)" is added to the deploy-staging pipeline. The job builds a macOS desktop application (.dmg) using Tauri, installs required dependencies via Homebrew, and uploads the binary as a GitHub pre-release artifact. Planning documentation outlines the implementation and decision rationale.

Changes

Cohort / File(s)	Summary
GitHub Actions Workflow .github/workflows/deploy-staging.yml	Adds a new "build-desktop" job that compiles the macOS desktop app using Tauri, installs macFUSE, configures PNPM/Node 22, and uploads the .dmg binary to a GitHub pre-release for staging tags.
Planning Documentation .planning/STATE.md, .planning/quick/017-desktop-binary-staging-release/017-PLAN.md, .planning/quick/017-desktop-binary-staging-release/017-SUMMARY.md	Adds planning documentation for quick task 017, including task summary, detailed plan, verification criteria, and updates to the state tracking file.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• feat: Phase 9.1 — Environment, DevOps & Staging Deployment #64: Introduced the initial deploy-staging workflow with build-api, build-tee, and build-web jobs; this PR adds the build-desktop job to the same workflow configuration.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: adding a desktop binary build capability to the staging deployment workflow.
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
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/desktop-binary-staging-release

---

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

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

.github/workflows/deploy-staging.yml (1)

116-118: macos-latest builds arm64-only — Intel Mac testers will need Rosetta 2

GitHub's macos-latest runner is now Apple Silicon (arm64). The produced .dmg will be an arm64-only binary. Testers on Intel Macs can still run it via Rosetta 2, but this isn't mentioned in the releaseBody. Consider either noting this in the release body or, when the project matures to production signing, building a universal binary via --target universal-apple-darwin.

💬 Optional: clarify arch in release body (Line 157)

-          releaseBody: 'Staging build for ${{ inputs.staging_tag || github.ref_name }}. macOS only (unsigned - right-click > Open to launch).'
+          releaseBody: 'Staging build for ${{ inputs.staging_tag || github.ref_name }}. macOS arm64 only (unsigned - right-click > Open to launch). Intel Macs require Rosetta 2.'

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/deploy-staging.yml around lines 116 - 118, The workflow
uses the build-desktop job with runs-on: macos-latest which is an Apple Silicon
(arm64) runner, so the produced .dmg is arm64-only; update the releaseBody to
explicitly note the artifact is arm64 and that Intel Mac testers must use
Rosetta 2, or alternately change the build step for build-desktop to produce a
universal binary when ready by adding the macOS packaging flag --target
universal-apple-darwin (used with your pack/forge/build command) and signing
pipeline adjustments; reference build-desktop, runs-on: macos-latest,
releaseBody, and --target universal-apple-darwin when making the change.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/deploy-staging.yml:
- Around line 127-128: The CI step that runs "brew install --cask macfuse" can
leave no fuse.pc so the vendored crate's build.rs (which does a pkg-config probe
and .unwrap()) will panic; update the workflow to ensure pkg-config can find
fuse.pc by either verifying the brew install produced fuse.pc in a pkg-config
searchable path and setting PKG_CONFIG_PATH accordingly, or replace the brew
step with downloading the macFUSE SDK from the macfuse releases and exporting
PKG_CONFIG_PATH to the SDK's pkgconfig dir (or use a prebuilt macOS
runner/workflow that includes FUSE headers) so the build.rs probe for "fuse" /
"osxfuse" succeeds instead of unwrapping a missing result.

---

Nitpick comments:
In @.github/workflows/deploy-staging.yml:
- Around line 116-118: The workflow uses the build-desktop job with runs-on:
macos-latest which is an Apple Silicon (arm64) runner, so the produced .dmg is
arm64-only; update the releaseBody to explicitly note the artifact is arm64 and
that Intel Mac testers must use Rosetta 2, or alternately change the build step
for build-desktop to produce a universal binary when ready by adding the macOS
packaging flag --target universal-apple-darwin (used with your pack/forge/build
command) and signing pipeline adjustments; reference build-desktop, runs-on:
macos-latest, releaseBody, and --target universal-apple-darwin when making the
change.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Check if fuser's build.rs exists and examine its contents
echo "=== Checking vendored fuser build.rs ==="
find apps/desktop/src-tauri/vendor/fuser -name "build.rs" -type f

Repository: FSM1/cipher-box

Length of output: 144

---

🏁 Script executed:

#!/bin/bash

# Look for PKG_CONFIG_PATH, FUSE_INCLUDE_DIR or any macfuse-related setup in fuser
echo "=== Searching for pkg-config and FUSE setup in vendored fuser ==="
rg -n "PKG_CONFIG_PATH|FUSE_INCLUDE|pkg.config|probe|macfuse" apps/desktop/src-tauri/vendor/fuser/ 2>/dev/null || echo "Pattern not found"

echo -e "\n=== Checking build.rs for platform-specific handling ==="
fd "build\.rs" apps/desktop/src-tauri/vendor/fuser -type f -exec head -50 {} \;

Repository: FSM1/cipher-box

Length of output: 4177

---

🏁 Script executed:

#!/bin/bash

# Check the actual deploy-staging workflow to see what steps run on macOS
echo "=== Checking deploy-staging.yml for macOS-specific setup ==="
grep -n "macos" .github/workflows/deploy-staging.yml -i
grep -n "macfuse\|fuse\|PKG_CONFIG" .github/workflows/deploy-staging.yml

Repository: FSM1/cipher-box

Length of output: 381

---

🏁 Script executed:

#!/bin/bash

# Check if there are any other workflows or setup scripts that handle macfuse installation
echo "=== Searching for macfuse references across the repo ==="
rg -l "macfuse|macFUSE" --type yaml --type sh

Repository: FSM1/cipher-box

Length of output: 115

---

🏁 Script executed:

#!/bin/bash

# Read the full build.rs to understand error handling
echo "=== Full build.rs content ==="
cat -n apps/desktop/src-tauri/vendor/fuser/build.rs

Repository: FSM1/cipher-box

Length of output: 2536

---

🏁 Script executed:

#!/bin/bash

# Check if there's a Cargo.lock or Cargo.toml at the root that shows how fuser is used
echo "=== Checking how fuser is configured in the tauri app's Cargo.toml ==="
grep -n "fuser\|libfuse" apps/desktop/src-tauri/Cargo.toml | head -20

Repository: FSM1/cipher-box

Length of output: 461

---

🏁 Script executed:

#!/bin/bash

# Check if there's any GitHub Actions setup or workaround scripts
echo "=== Looking for any pre-build setup or environment scripts ==="
fd "setup|install|pre" .github/workflows/ -type f
cat -n .github/workflows/deploy-staging.yml | head -140

Repository: FSM1/cipher-box

Length of output: 4923

---

brew install --cask macfuse may fail or not properly install pkg-config files on GitHub's hosted macOS runners, causing the Rust build to fail

The vendored fuser's build.rs (line 31) has a hard .unwrap() on the pkg-config probe for fuse or osxfuse. If brew install --cask macfuse succeeds but doesn't lay down the fuse.pc pkg-config file — which can happen if the kernel extension approval is required but unavailable in a headless CI environment — the build will panic during compilation.

Confirm that brew install --cask macfuse successfully installs fuse.pc to a location discoverable by pkg-config on a GitHub Actions macOS runner, or use an alternative approach such as:

• Downloading the macFUSE SDK directly from macFUSE releases and setting PKG_CONFIG_PATH manually
• Using a pre-built GitHub Actions workflow that already includes FUSE headers

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/deploy-staging.yml around lines 127 - 128, The CI step
that runs "brew install --cask macfuse" can leave no fuse.pc so the vendored
crate's build.rs (which does a pkg-config probe and .unwrap()) will panic;
update the workflow to ensure pkg-config can find fuse.pc by either verifying
the brew install produced fuse.pc in a pkg-config searchable path and setting
PKG_CONFIG_PATH accordingly, or replace the brew step with downloading the
macFUSE SDK from the macfuse releases and exporting PKG_CONFIG_PATH to the SDK's
pkgconfig dir (or use a prebuilt macOS runner/workflow that includes FUSE
headers) so the build.rs probe for "fuse" / "osxfuse" succeeds instead of
unwrapping a missing result.