ci(desktop): surface silent x86_64 build failures#7227
Conversation
The omi-desktop-swift-release workflow's "Build Swift app" step had an
existence check after the arm64 build but not after x86_64. If
`xcrun swift build --triple x86_64-apple-macosx` exits 0 without
producing the binary (e.g. cache poisoning, target skip), the step
silently "succeeds" and the next step ("Create universal app bundle")
fails with a generic "MISSING binary" message — no traceback to the
real cause. Burned a build (Codemagic 6a010cef → 6a011902) trying to
ship v0.11.380.
Add a symmetric check that exits early with a directory listing if
x86_64 didn't produce output. The actual swift-build error remains
visible in the Build Swift step's stderr, but now the step status
reflects reality.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Greptile SummaryThis PR adds a post-build existence check for the x86_64 Swift binary, mirroring the equivalent check that was already present for arm64. Previously, a silent x86_64 build failure (exit 0 but no output) would not be caught until the
Confidence Score: 5/5Safe to merge — the change is a targeted one-step guard that exits early with diagnostic output; it does not alter build logic, artifact paths, or downstream steps. The addition mirrors an existing, proven pattern directly above it. Quoting is correct for the space-containing BINARY_NAME, || true prevents premature failure before the explicit exit 1, and the diagnostic listings give more information than their arm64 counterparts. No build logic is changed. No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Build arm64\nxcrun swift build --triple arm64-apple-macosx] --> B{ARM64_PATH exists?}
B -- No --> C[Print error + ls diagnostics\nexit 1]
B -- Yes --> D[cp arm64 binary to /tmp/OmiComputer-arm64]
D --> E[Build x86_64\nxcrun swift build --triple x86_64-apple-macosx]
E --> F{X86_64_PATH exists?\n✅ NEW CHECK}
F -- No --> G[Print error + ls -la diagnostics\nexit 1]
F -- Yes --> H[Log arch info]
H --> I[Create universal app bundle\nlipo -create arm64 x86_64]
Reviews (1): Last reviewed commit: "ci(desktop): add x86_64 existence check ..." | Re-trigger Greptile |
Reverts #7224. The change was merged before being validated locally; we want to test the dev-backend routing on a named local bundle first (using the `OMI_FORCE_DEV_BACKENDS` override I added in that PR — except the env-var didn't actually reach the launched .app because `run.sh` loads URLs via a baked `Contents/Resources/.env`, not shell env). Reverting on `main`, validating locally, then redoing. The diagnostic PR #7227 stays — that's an unrelated workflow hardening that's useful regardless. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Reapplies #7224 after the #7230 revert. Verified locally this time: - Named bundle (`com.omi.omi-beta-dev-test`) launched with shell-bundled dev URLs (`OMI_PYTHON_API_URL=https://api.omiapi.com/`, `OMI_DESKTOP_API_URL=https://desktop-backend-dt5lrfkkoa-uc.a.run.app/`). - Signed in with `kodjima33@gmail.com` — landed on **prod UID `viUv7GtdoHXbK1UBCDlPuTDuPgJ2`** (not a ghost dev UID). - Existing chat history and tasks loaded. - New requests go through dev backend: `POST https://api.omiapi.com/v2/desktop/messages`, `/v3/memories`, `/v1/action-items` — all succeeding, AgentSync pushing rows. - Confirms dev backend's `SERVICE_ACCOUNT_JSON`, `FIREBASE_API_KEY`, `FIREBASE_PROJECT_ID` are all on prod Firebase (`based-hardware`), so dev-issued custom tokens resolve to the same prod UID. This time the change ships through the existing #7227 diagnostic patch (already on main), so if Codemagic's universal-bundle step trips again we'll get a real error instead of a 0.6s opaque failure. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Why
The
omi-desktop-swift-releaseworkflow's Build Swift app step had an existence check after the arm64 build but not after x86_64. Ifxcrun swift build --triple x86_64-apple-macosxexits 0 without producing the binary, the step silently "succeeds" and the next step (Create universal app bundle) fails with a generic "MISSING binary" message — no traceback to the real cause.Burned Codemagic build 6a010cef → rebuild 6a011902 on v0.11.380. Same failure both times:
Create universal app bundlefails in 0.6s;Build Swift appreports success in 601s, 33s shorter than the prior 634s success — strongly implying the x86_64 build was silently skipped.What this changes
Add a symmetric existence check after the x86_64 build (mirroring the arm64 one). If x86_64 didn't produce output, exit early with a directory listing. The actual swift-build error (if any) remains visible in this step's stderr.
Test plan
🤖 Generated with Claude Code