Skip to content

ci(desktop): surface silent x86_64 build failures#7227

Merged
kodjima33 merged 1 commit into
mainfrom
worktree-fix-desktop-build-diagnostics
May 11, 2026
Merged

ci(desktop): surface silent x86_64 build failures#7227
kodjima33 merged 1 commit into
mainfrom
worktree-fix-desktop-build-diagnostics

Conversation

@kodjima33
Copy link
Copy Markdown
Collaborator

Why

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, 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 6a010cefrebuild 6a011902 on v0.11.380. Same failure both times: Create universal app bundle fails in 0.6s; Build Swift app reports 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

  • Merge to main → auto-release bumps to v0.11.381 → Codemagic runs.
  • If x86_64 build is silently failing: the next attempt fails with a clear error pointing at the swift-build invocation (i.e. we'll then know what to fix in the code).
  • If x86_64 builds fine and the universal-bundle step still fails: rules out my hypothesis and points elsewhere.

🤖 Generated with Claude Code

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>
@kodjima33 kodjima33 merged commit 28c4a35 into main May 11, 2026
3 checks passed
@kodjima33 kodjima33 deleted the worktree-fix-desktop-build-diagnostics branch May 11, 2026 00:06
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented May 11, 2026

Greptile Summary

This 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 Create universal app bundle step, where a generic "missing binary" error obscured the root cause.

  • Symmetric guard added: If Desktop/.build/x86_64-apple-macosx/release/$BINARY_NAME is absent after xcrun swift build --triple x86_64-apple-macosx, the step now exits immediately with diagnostic directory listings pointing directly at the swift-build invocation.
  • Diagnostic output is slightly more detailed than the arm64 equivalent (uses ls -la with head -30), which is a net improvement for debuggability.

Confidence Score: 5/5

Safe 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

Filename Overview
codemagic.yaml Adds symmetric x86_64 binary existence check in the Build Swift app step, mirroring the pre-existing arm64 guard; diagnostics are well-formed and correctly quoted for the space-containing BINARY_NAME.

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]
Loading

Reviews (1): Last reviewed commit: "ci(desktop): add x86_64 existence check ..." | Re-trigger Greptile

kodjima33 added a commit that referenced this pull request May 11, 2026
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)
kodjima33 added a commit that referenced this pull request May 11, 2026
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant