ci(desktop): use macos-latest-xlarge runner for faster builds#1372
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe GitHub Actions workflow Changes
Sequence Diagram(s)sequenceDiagram
participant GH as "GitHub Actions\n(runner: macos-latest-large)"
participant Repo as "Repository\n(workspace/apps/desktop)"
participant Builder as "electron-builder"
participant Artifact as "GitHub Artifacts"
Note over GH,Repo: Start (checkout, setup Bun, cache, install)
GH->>Repo: Run prepare native modules & resources\n(`npm run copy:native-modules`, `npm run download:claude`)
GH->>Builder: Build app bundle\n(`npx electron-builder --dir --arm64`)
Builder-->>Repo: Output build directory (release/mac-arm64)
GH->>Builder: Package prepackaged release\n(`npx electron-builder --prepackaged ... --publish never`)
Builder-->>Repo: Produce DMG, ZIP, update manifest
GH->>Artifact: Upload DMG, ZIP, update manifest (retention, arch-specific paths)
Note over Artifact,GH: End
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
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. Comment |
saddlepaddle
had a problem deploying
to
production
GitHub Actions
Failure
🧹 Preview Cleanup CompleteThe following preview resources have been cleaned up:
Thank you for your contribution! 🎉 |
saddlepaddle
had a problem deploying
to
production
GitHub Actions
Failure
saddlepaddle
had a problem deploying
to
production
GitHub Actions
Failure
saddlepaddle
temporarily deployed
to
production
GitHub Actions
Inactive
Breaks the monolithic "Build Electron app" step into 3 discrete steps to get visibility into where time is spent: 1. Prepare native modules & resources 2. Build unsigned app bundle 3. Code sign, notarize & package
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/build-desktop.yml:
- Line 34: The workflow uses an Intel runner "macos-latest-large" while the
build matrix targets arm64; change the runner to an Apple Silicon macOS runner
(e.g., replace "macos-latest-large" with "macos-latest-xlarge" or another
arm64-capable runner) or adjust the matrix to use x64 so runner and target
architecture match; ensure the string "macos-latest-large" is replaced wherever
the job's runs-on is defined and that the matrix entry "arch: [arm64]" remains
consistent with the selected runner.
| build: | ||
| name: Build - macOS (${{ matrix.arch }}) | ||
| runs-on: macos-latest | ||
| runs-on: macos-latest-large |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions macos-latest-large macos-latest-xlarge runner specifications architecture Apple Silicon Intel
💡 Result:
GitHub Actions macOS larger runners: specs + CPU architecture
| Workflow label | Runner “size” | CPU / Arch | vCPU | RAM | SSD | Notes |
|---|---|---|---|---|---|---|
macos-latest-large |
Large | Intel x64 | 12 | 30 GB | 14 GB | “-latest-large” tracks the latest GA Intel large image. [1] |
macos-latest-xlarge |
XLarge | Apple Silicon arm64 (M2 / M2 Pro) | 5 | 14 GB | 14 GB | Includes GPU hardware acceleration (8‑core GPU mentioned for the M2 Pro rollout). [1][2] |
What “latest” maps to (images)
- In the
actions/runner-imagesrepo, macOS 15 (Intel) is labeledmacos-latest-large/macos-15-large(and alsomacos-15-intel). [3] - macOS 15 Arm64 is labeled
macos-latest/macos-15/macos-15-xlarge. [3]
Sources
[1] GitHub Docs — “Larger runners reference” (macOS large/xlarge table + specs). (docs.github.com)
[2] GitHub Changelog (July 2025) — XLarge upgraded to M2 Pro, 5‑core CPU, 8‑core GPU, 14 GB RAM, 14 GB storage. (github.blog)
[3] actions/runner-images — “Available Images” (label ↔ image mapping, including macos-latest-large and macos-15-xlarge). (github.com)
Citations:
- 1: https://docs.github.com/en/actions/reference/runners/larger-runners
- 2: https://github.blog/changelog/2025-07-16-github-actions-now-offers-m2-pro-powered-hosted-runners-in-public-preview/
- 3: https://github.com/actions/runner-images?utm_source=openai
🏁 Script executed:
# Check the matrix configuration in the workflow file
head -50 .github/workflows/build-desktop.yml | tail -20Repository: superset-sh/superset
Length of output: 437
Runner architecture mismatch: macos-latest-large is Intel x86_64, but the build targets arm64 Apple Silicon.
The workflow uses macos-latest-large (Intel x64 runner) but the matrix specifies arch: [arm64]. On GitHub Actions, macos-latest-large is an Intel runner, while macos-latest-xlarge is the Apple Silicon (arm64) runner required for native arm64 builds. Building an arm64 application on an Intel runner will fail or produce incorrect output.
Proposed fix
- runs-on: macos-latest-large
+ runs-on: macos-latest-xlarge📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| runs-on: macos-latest-large | |
| runs-on: macos-latest-xlarge |
🤖 Prompt for AI Agents
In @.github/workflows/build-desktop.yml at line 34, The workflow uses an Intel
runner "macos-latest-large" while the build matrix targets arm64; change the
runner to an Apple Silicon macOS runner (e.g., replace "macos-latest-large" with
"macos-latest-xlarge" or another arm64-capable runner) or adjust the matrix to
use x64 so runner and target architecture match; ensure the string
"macos-latest-large" is replaced wherever the job's runs-on is defined and that
the matrix entry "arch: [arm64]" remains consistent with the selected runner.
--dir mode ignores mac.target.arch from config and defaults to host arch (x64 on macos-latest-large). Explicitly pass --arm64 so the unsigned bundle lands in release/mac-arm64 as expected.
saddlepaddle
temporarily deployed
to
production
GitHub Actions
Inactive
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/build-desktop.yml:
- Around line 99-107: The workflow is building native modules with the host
architecture (copied by the copy:native-modules step) but then passing --arm64
to electron-builder, causing an arch mismatch; update the GitHub Actions runner
used for this job to an arm64 macOS runner (macos-latest-xlarge) so the
copy:native-modules step produces arm64 native modules that match the
electron-builder --arm64 bundle, ensuring download:claude and the Build app
bundle step run on the same architecture.
🧹 Nitpick comments (1)
.github/workflows/build-desktop.yml (1)
119-141: Artifact uploads look correct; minor note on manifest naming.The DMG and ZIP artifact names include
${{ matrix.arch }}but the update manifest (Line 138) does not. This is fine with the current single-arch matrix (arm64only), but ifx86_64is added later, parallel jobs will collide on the artifact name${{ inputs.artifact_prefix }}-mac-update-manifest.Future-proof the manifest artifact name
- name: ${{ inputs.artifact_prefix }}-mac-update-manifest + name: ${{ inputs.artifact_prefix }}-mac-${{ matrix.arch }}-update-manifest
| - name: Prepare native modules & resources | ||
| working-directory: apps/desktop | ||
| run: | | ||
| bun run copy:native-modules | ||
| bun run download:claude | ||
|
|
||
| - name: Build app bundle | ||
| working-directory: apps/desktop | ||
| run: npx electron-builder --dir --arm64 --config ${{ inputs.electron_builder_config }} -c.mac.identity=null |
There was a problem hiding this comment.
Native modules will be wrong architecture if runner mismatch isn't fixed.
copy:native-modules (Line 102) copies modules built for the host architecture. On an Intel runner (macos-latest-large), these will be x64 binaries. The subsequent --arm64 flag on Line 107 produces an arm64 app bundle, but it will contain x64 native modules — resulting in a broken application at runtime.
This is a downstream consequence of the runner issue on Line 34. Once the runner is switched to macos-latest-xlarge (arm64), both the native modules and the --arm64 flag will be consistent.
🤖 Prompt for AI Agents
In @.github/workflows/build-desktop.yml around lines 99 - 107, The workflow is
building native modules with the host architecture (copied by the
copy:native-modules step) but then passing --arm64 to electron-builder, causing
an arch mismatch; update the GitHub Actions runner used for this job to an arm64
macOS runner (macos-latest-xlarge) so the copy:native-modules step produces
arm64 native modules that match the electron-builder --arm64 bundle, ensuring
download:claude and the Build app bundle step run on the same architecture.
--prepackaged release/mac-arm64 wraps the directory in another .app, creating a double-nested bundle. It needs the path to the actual .app bundle (e.g. release/mac-arm64/Superset Canary.app).
saddlepaddle
temporarily deployed
to
production
GitHub Actions
Inactive
saddlepaddle
had a problem deploying
to
preview
GitHub Actions
Failure
saddlepaddle
had a problem deploying
to
preview
GitHub Actions
Failure
saddlepaddle
had a problem deploying
to
preview
GitHub Actions
Failure
saddlepaddle
had a problem deploying
to
preview
GitHub Actions
Failure
saddlepaddle
had a problem deploying
to
preview
GitHub Actions
Failure
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @.github/workflows/build-desktop.yml:
- Line 117: The workflow step that runs npx electron-builder uses a fragile
command that parses ls output to build the --prepackaged path; replace that with
a robust glob/find that selects the .app bundle (e.g., match '*.app' in
release/mac-arm64 and quote the result) so the --prepackaged argument always
points to the single .app (update the run line that currently contains npx
electron-builder --prepackaged "release/mac-arm64/$(ls release/mac-arm64/)" to
use a quoted glob or a find command that prints the first '*.app' match).
| APPLE_APP_SPECIFIC_PASSWORD: ${{ secrets.APPLE_ID_PASSWORD }} | ||
| APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }} | ||
| run: bun run package -- --publish never --config ${{ inputs.electron_builder_config }} | ||
| run: npx electron-builder --prepackaged "release/mac-arm64/$(ls release/mac-arm64/)" --config ${{ inputs.electron_builder_config }} --publish never |
There was a problem hiding this comment.
Fragile: parsing ls output to resolve the .app bundle path.
If release/mac-arm64/ contains any unexpected files (.DS_Store, build metadata, etc.), ls will return multiple entries and break the --prepackaged argument. Use a glob instead for robustness.
Proposed fix — use a glob to match the .app bundle
- run: npx electron-builder --prepackaged "release/mac-arm64/$(ls release/mac-arm64/)" --config ${{ inputs.electron_builder_config }} --publish never
+ run: npx electron-builder --prepackaged release/mac-arm64/*.app --config ${{ inputs.electron_builder_config }} --publish neverIf the app name contains spaces and the glob must be quoted, use find instead:
run: npx electron-builder --prepackaged "$(find release/mac-arm64 -maxdepth 1 -name '*.app' -print -quit)" --config ${{ inputs.electron_builder_config }} --publish never📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| run: npx electron-builder --prepackaged "release/mac-arm64/$(ls release/mac-arm64/)" --config ${{ inputs.electron_builder_config }} --publish never | |
| run: npx electron-builder --prepackaged release/mac-arm64/*.app --config ${{ inputs.electron_builder_config }} --publish never |
🤖 Prompt for AI Agents
In @.github/workflows/build-desktop.yml at line 117, The workflow step that runs
npx electron-builder uses a fragile command that parses ls output to build the
--prepackaged path; replace that with a robust glob/find that selects the .app
bundle (e.g., match '*.app' in release/mac-arm64 and quote the result) so the
--prepackaged argument always points to the single .app (update the run line
that currently contains npx electron-builder --prepackaged
"release/mac-arm64/$(ls release/mac-arm64/)" to use a quoted glob or a find
command that prints the first '*.app' match).
electron-builder's --prepackaged skips the signing phase entirely. Move signing env vars to the --dir build step so the .app is properly signed and notarized. The prepackaged step then just creates DMG/ZIP from the already-signed bundle.
saddlepaddle
temporarily deployed
to
production
GitHub Actions
Inactive
saddlepaddle
had a problem deploying
to
preview
GitHub Actions
Failure
saddlepaddle
had a problem deploying
to
preview
GitHub Actions
Failure
saddlepaddle
had a problem deploying
to
preview
GitHub Actions
Failure
saddlepaddle
had a problem deploying
to
preview
GitHub Actions
Failure
saddlepaddle
had a problem deploying
to
preview
GitHub Actions
Failure
1 participant
Summary
macos-latest(3 cores, 7GB RAM) tomacos-latest-xlarge(12 cores, 30GB RAM) for faster Electron buildsTest plan
Summary by CodeRabbit