ci(codemagic): Windows desktop build workflow (blocked on billing plan) #5

Closed
claude wants to merge 0 commits from feat/windows-desktop-ci into main
Contributor

Adds a desktop-windows Codemagic workflow to build the Tauri/CEF desktop app's Windows installer (NSIS/MSI) — the owner asked for a .exe release artifact, and this dev box is Linux-only so cross-compiling a CEF-based app isn't realistic; Codemagic's Windows machine is the only practical option.

Status: blocked on a billing-plan limit, not a config bug

Triggered twice via the Codemagic API and read the actual failure reasons (not just top-level status):

  1. instance_type: windows_x2 → "The selected instance type is not available with the current billing plan." This is Codemagic account-level, not something in this repo or workflow to fix.
  2. Tried windows_x1 as a fallback, in case windows_x2 specifically was the paid tier — Codemagic's own schema validation rejected it outright: windows_x2 is the only valid Windows instance_type value at all (full enum: mac_mini, mac_mini_m1, mac_mini_m2, mac_mini_m4, mac_studio_m4_max, mac_pro, linux, linux_x2, linux_x4, windows_x2). So there's no cheaper Windows option to fall back to — reverted to windows_x2, which is at least the syntactically correct value, so this workflow will start working the moment the account's plan includes it.

The existing account plan clearly includes Mac machines (mac_mini_m2, used by ios-release/build-unsigned, both working tonight) but not windows_x2. This needs the owner to upgrade the Codemagic plan or otherwise enable Windows machine access — nothing else in this PR can unblock it.

What's in this PR

  • codemagic.yaml: new desktop-windows workflow — npm ci → npm run build (matrix-core + web, required before the desktop build) → cd apps/desktop && npx tauri build --bundles nsis,msi. Triggers on push/PR to any branch, matching build-unsigned's pattern. Does not touch ios-release/build-unsigned or any signing config.
  • Unsigned — Windows Authenticode code-signing needs a real certificate the owner would buy/provide, same gap RELEASE.md already documents for macOS/Windows packaging.
  • Untested beyond config validation, since it's never actually run on a real Windows machine yet (blocked above) — there's a real chance the feat/cef Tauri branch's CEF binary distribution has Windows-specific packaging issues once it does run (only Linux appimage/deb have ever been exercised for this app), worth being aware of as a next problem once the plan issue is resolved.

Gate

npm run build, npm test (471/471 + 1 skip), npm run lint (0 errors) all green in a worktree — this PR only touches CI config, no app code.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

Adds a `desktop-windows` Codemagic workflow to build the Tauri/CEF desktop app's Windows installer (NSIS/MSI) — the owner asked for a `.exe` release artifact, and this dev box is Linux-only so cross-compiling a CEF-based app isn't realistic; Codemagic's Windows machine is the only practical option. ## Status: blocked on a billing-plan limit, not a config bug Triggered twice via the Codemagic API and read the actual failure reasons (not just top-level status): 1. `instance_type: windows_x2` → **"The selected instance type is not available with the current billing plan."** This is Codemagic account-level, not something in this repo or workflow to fix. 2. Tried `windows_x1` as a fallback, in case `windows_x2` specifically was the paid tier — Codemagic's own schema validation rejected it outright: `windows_x2` is the **only** valid Windows `instance_type` value at all (full enum: `mac_mini, mac_mini_m1, mac_mini_m2, mac_mini_m4, mac_studio_m4_max, mac_pro, linux, linux_x2, linux_x4, windows_x2`). So there's no cheaper Windows option to fall back to — reverted to `windows_x2`, which is at least the syntactically correct value, so this workflow will start working the moment the account's plan includes it. The existing account plan clearly includes Mac machines (`mac_mini_m2`, used by `ios-release`/`build-unsigned`, both working tonight) but not `windows_x2`. **This needs the owner to upgrade the Codemagic plan or otherwise enable Windows machine access** — nothing else in this PR can unblock it. ## What's in this PR - `codemagic.yaml`: new `desktop-windows` workflow — `npm ci` → `npm run build` (matrix-core + web, required before the desktop build) → `cd apps/desktop && npx tauri build --bundles nsis,msi`. Triggers on push/PR to any branch, matching `build-unsigned`'s pattern. Does not touch `ios-release`/`build-unsigned` or any signing config. - **Unsigned** — Windows Authenticode code-signing needs a real certificate the owner would buy/provide, same gap `RELEASE.md` already documents for macOS/Windows packaging. - Untested beyond config validation, since it's never actually run on a real Windows machine yet (blocked above) — there's a real chance the `feat/cef` Tauri branch's CEF binary distribution has Windows-specific packaging issues once it does run (only Linux appimage/deb have ever been exercised for this app), worth being aware of as a *next* problem once the plan issue is resolved. ## Gate `npm run build`, `npm test` (471/471 + 1 skip), `npm run lint` (0 errors) all green in a worktree — this PR only touches CI config, no app code. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New desktop-windows workflow (windows_x2 instance) builds the Tauri/CEF
desktop app's NSIS/MSI installer on a real Windows machine, since this
dev box is Linux-only and cross-compiling a CEF-based app isn't
realistic. Unsigned - Authenticode code-signing needs a real cert the
owner would provide, matches RELEASE.md's existing known gap.

Does not touch the existing ios-release/build-unsigned workflows or any
signing config.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ci(codemagic): revert to windows_x2 (the only valid Windows enum value)
Some checks failed
CI / build-and-test (pull_request) Has been cancelled
CI / e2e (pull_request) Has been cancelled
544fb73657
Confirmed via Codemagic's own schema validation error that windows_x2 is
the ONLY Windows instance_type Codemagic supports at all - windows_x1
doesn't exist. The real blocker is billing-plan access to windows_x2, not
config correctness (see PR description).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Author
Contributor

Merged into main at 0ca16bc, clean merge (config-only addition, no conflicts). Gate results: build clean, 476 unit tests passed (1 skipped), lint 0 errors, e2e 15/15 passed. codemagic.yaml validated as parseable YAML; the new desktop-windows workflow is unsigned (no Authenticode section touched) and inert until the Codemagic account gets Windows instance access - merging now means main already has the ready-to-go workflow for when that billing limit is lifted. Closing.

Merged into main at 0ca16bc, clean merge (config-only addition, no conflicts). Gate results: build clean, 476 unit tests passed (1 skipped), lint 0 errors, e2e 15/15 passed. codemagic.yaml validated as parseable YAML; the new desktop-windows workflow is unsigned (no Authenticode section touched) and inert until the Codemagic account gets Windows instance access - merging now means main already has the ready-to-go workflow for when that billing limit is lifted. Closing.
claude closed this pull request 2026-09-16 18:44:39 +00:00
Some checks failed
CI / build-and-test (pull_request) Has been cancelled
CI / e2e (pull_request) Has been cancelled

Pull request closed

Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
thatumi/JorKonvo!5
No description provided.