* Add R2 dual-write for nightly appcast and DMGs
Upload nightly DMGs and appcast to Cloudflare R2 (files.cmux.com)
alongside the existing GitHub Release assets. R2 uses atomic PutObject
so the appcast never 404s during replacement, fixing the transient
SUDownloadError 2001 that occurs when GitHub Release assets are
being overwritten.
DMGs are uploaded before the appcast so the feed never references a
file that doesn't exist yet. The GitHub Release upload is unchanged,
so existing nightly users are unaffected.
A follow-up PR will switch the Sparkle feed URL in the app bundle
from GitHub Releases to R2 after manual verification.
* Add continue-on-error to R2 steps
R2 upload failures should not block the existing GitHub Release
publish. This keeps the nightly pipeline safe while R2 is new.
* Add R2 dual-write for stable release appcast and DMG
Same pattern as nightly: upload DMG then appcast to R2
(files.cmux.com/stable/) alongside the GitHub Release.
Both steps use continue-on-error so R2 failures can't
block the release.
* Address review feedback: cache headers, no double build, AWS CLI guard
- Add Cache-Control headers: immutable versioned DMGs get max-age=1yr,
mutable appcast.xml and latest DMG get no-cache to prevent stale CDN
- Replace separate appcast generation step with sed URL replacement,
avoiding a second Sparkle clone+build (signature is over DMG content,
not the URL)
- Add AWS CLI availability check with fallback brew install
---------
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
Match the nightly workflow's universal build approach so stable releases
support both Apple Silicon and Intel Macs. Adds -destination, ARCHS,
ONLY_ACTIVE_ARCH=NO flags and a post-build architecture verification step.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* Switch release builds to macOS Tahoe runner
Use warp-macos-26-arm64-6x for release builds to match nightly. Also add
a dry-run artifact upload path for workflow_dispatch so the release
pipeline can be tested without creating a real release.
* Gate release upload on event_name, not just ref prefix
Prevents workflow_dispatch triggered on a tag ref from accidentally
uploading real release assets.
---------
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
* Migrate CI/CD to WarpBuild, consolidate test jobs
Replace all macOS runner labels across workflows:
- depot-macos-latest → warp-macos-15-arm64-6x
- macos-15 → warp-macos-15-arm64-6x
- macos-14 → warp-macos-14-arm64-6x
Consolidates tests + tests-depot into a single tests job that runs
unit tests, regressions, UI tests, and lag tests sequentially on one
WarpBuild runner. Ubuntu jobs remain on ubuntu-latest.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Upgrade stale zig on runners that have an outdated version pre-installed
WarpBuild macos-14 ships zig 0.15.1 but the project requires 0.15.2.
The install step skipped because zig was found, just outdated.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Pin zig 0.15.2 via direct tarball instead of Homebrew
Homebrew's zig bottle for macOS 14 (Sonoma) is stuck at 0.15.1 but the
ghostty submodule requires 0.15.2. Download zig directly from
ziglang.org to guarantee the correct version on all runner images.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Fix zig tarball URL: arch-os order is aarch64-macos, not macos-aarch64
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Create /usr/local/bin and /usr/local/lib before copying zig
WarpBuild runners don't have /usr/local/lib by default.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add 20-min timeout to WarpBuild jobs
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Fix UI test hang: stream output instead of variable capture, use GitHub runner for macOS 14
The OUTPUT=$(...) pattern buffers all xcodebuild output into a bash
variable. For the full cmux scheme (build + UI tests), this can be
hundreds of MB, causing the shell to hang. Replace with tee streaming.
macOS 14 on WarpBuild consistently hangs (unit tests timeout at 20min
vs 4min on macOS 15, same M4 Pro hardware). Use GitHub-hosted macos-14
runner for compat tests instead, which works on main today.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Split UI tests to GitHub-hosted runner (WarpBuild can't activate GUI apps)
WarpBuild macOS VMs leave XCUIApplication stuck in "Running Background"
state, causing every UI test to burn ~62s waiting for activation and
timing out the job. Root cause: WarpBuild ephemeral VMs don't provide
a full GUI session for app activation.
Split CI into parallel jobs:
- tests: WarpBuild (unit tests + regressions, ~6 min)
- tests-ui: GitHub-hosted macos-15 (UI tests + lag regression)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Move tests-ui to WarpBuild with TCC permission grants
Grant accessibility, post-event, and screen capture TCC permissions
to Xcode and XCTest processes on WarpBuild ephemeral VMs. This should
fix "Failed to activate application (Running Background)" errors that
prevent XCUITests from bringing the app to foreground.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add GUI session diagnostics and DevToolsSecurity for WarpBuild UI tests
Add session diagnostics (who, console user, GUI domain, WindowServer,
loginwindow) to understand WarpBuild VM session state. Also enable
DevToolsSecurity and security authorizationdb for XCTest process
control. Try bootstrapping GUI session if missing.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Fix TCC permissions: use Xcode-Helper + user DB (CircleCI approach)
Previous TCC grants used wrong client IDs (com.apple.dt.Xcode) and
only wrote to the system database. CircleCI's proven approach grants:
- kTCCServiceAccessibility to com.apple.dt.Xcode-Helper (not Xcode)
- kTCCServiceDeveloperTool to com.apple.Terminal
- Both system AND user-level TCC databases
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Reduce UI test timeout to 15s for WarpBuild expected failures
WarpBuild Virtualization.framework VMs cannot activate macOS GUI apps
(XCUIApplication stuck "Running Background"). Tests still execute and
report expected failures. But the 62s per-test activation timeout
makes 30+ tests take 30+ minutes total.
Set per-test timeout to 15s so expected failures resolve quickly.
Full interactive UI test coverage runs via test-e2e.yml on
GitHub-hosted runners with proper display support.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Replace XCUITest run with build + lag regression on WarpBuild
WarpBuild Virtualization.framework VMs cannot activate macOS GUI apps
(XCUIApplication stuck "Running Background" with 62s activation
timeout per test). Tried TCC permissions, DevToolsSecurity, virtual
display, reduced timeouts, nothing fixes the framework-level issue.
Replace tests-ui job with tests-build-and-lag:
- Build the full cmux scheme (verifies compilation)
- Run workspace churn typing-lag regression (socket-based, no GUI)
- XCUITests run via test-e2e.yml on GitHub-hosted runners
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Move macOS 14 compat to WarpBuild (no GitHub-hosted runners)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add diagnostic workflow to probe WarpBuild GUI activation
Tests multiple app activation approaches on WarpBuild VMs:
- open -a, NSWorkspace, NSRunningApplication.activate, osascript
- Virtual display state before/after CGVirtualDisplay
- TCC/accessibility permissions, Quartz session info
- VM type detection
This is a workflow_dispatch-only diagnostic to determine if
XCUITest can work on WarpBuild with the right configuration.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Trigger GUI probe on branch push (workflow_dispatch needs main)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Rewrite GUI probe with Swift (Python lacks AppKit on WarpBuild)
v1 failed because WarpBuild's Python isn't a framework build and
can't import AppKit/Quartz. v2 uses a compiled Swift binary to test
NSRunningApplication.activate(), osascript, Quartz session state,
display info, and AX trust.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* GUI probe v3: try 5 approaches to unlock WarpBuild screen
1. defaults write (screensaver, loginwindow, pmset)
2. automationmodetool enable-automationmode-without-authentication
3. CGSSessionSetScreenLocked private API + System Events keystroke
4. sysadminctl -screenLock off + keychain unlock
5. CGEvent simulation (mouse move + Return key to dismiss lock)
Each approach is followed by an activation check to see if it worked.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Test GUI activation on macOS 14, 15, and 26 (Tahoe)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add DerivedData and GhosttyKit caching to CI workflows
Major caching improvements across ci.yml and ci-macos-compat.yml:
- Cache GhosttyKit.xcframework keyed on ghostty submodule SHA
(skip download on cache hit)
- Cache DerivedData keyed on OS + Xcode version + Package.resolved +
project.pbxproj (enables incremental builds across runs)
- Remove explicit DerivedData wipe (rely on cache key invalidation)
- Use download-prebuilt-ghosttykit.sh in compat workflow too
This should significantly speed up macOS 14 compat tests which were
taking 20+ min due to full recompilation every run.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Bump macOS 14 compat timeout to 45 min for cold cache seeding
The DerivedData cache wasn't saved because the job timed out at 30 min,
causing the post-job cache save step to be skipped. 45 min gives enough
headroom for the first uncached run to complete and seed the cache.
Subsequent runs should be much faster with incremental builds.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Use Depot runners for E2E tests (WarpBuild has screen lock on macOS 15/26)
WarpBuild VMs on macOS 15 and 26 have CGSSessionScreenIsLocked=1, which
prevents XCUIApplication activation. Depot runners have working GUI
activation. Can switch back to WarpBuild once they fix the VM images.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Skip smoke test on macOS 14 compat, remove GUI diagnostic workflow
macOS 14 was slow because it built the full app (cmux scheme) on top of
unit tests (cmux-unit scheme). Unit tests are the real compat check;
smoke test runs on macOS 15 only. Also removes the temporary
test-warpbuild-gui.yml diagnostic workflow.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Replace Sonoma with Tahoe in compat matrix, drop macOS 14
Swap macOS 14 (Sonoma) for macOS 26 (Tahoe). Smoke test runs on
macOS 15 only (WarpBuild screen lock blocks app activation on 26).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Drop macOS 26 from compat matrix (zig 0.15.2 linker failure)
Zig 0.15.2 can't link against the macOS 26 (Tahoe) SDK: undefined
symbols for basic libc functions (_abort, _free, _fork, etc.). The zig
toolchain needs an update to support Tahoe. Keep macOS 15 only for now.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* Cache Swift packages across CI runs
Add actions/cache for the SPM cloned source packages directory so
subsequent runs skip fetching Sparkle, sentry-cocoa, swift-markdown-ui,
posthog-ios, and NetworkImage from GitHub each time.
- nightly/release: replace the no-op SwiftPM cache step with
actions/cache + -clonedSourcePackagesDirPath on xcodebuild
- ci/ci-macos-compat/test-e2e: add actions/cache before the existing
resolve step, stop deleting the cache dir each run
* Include runner in test-e2e cache key
Consistent with ci-macos-compat.yml which uses matrix.os in the key.
* Migrate all workflows from self-hosted Mac Mini to Depot runners
Move CI, nightly, and release workflows to depot-macos-latest. Replace
zig GhosttyKit builds with pre-built xcframework downloads. Add virtual
display for CI UI tests. Remove concurrency groups (ephemeral VMs don't
need them).
* Add per-test timeout to CI UI tests to prevent hangs on Depot
SidebarResizeUITests hangs on headless Depot runners due to mouse drag
simulation issues. Adding -maximum-test-execution-time-allowance 120
(matching test-depot.yml) ensures individual tests timeout after 2 min
instead of blocking the entire run.
* Skip SidebarResizeUITests in CI on Depot runners
Mouse drag simulation hangs on headless Depot runners even with a
virtual display. The per-test timeout doesn't prevent the hang either.
Skip this test class in CI; it still runs fine on local machines.
* Handle XCTExpectFailure in CI UI tests (exit 65 with 0 unexpected)
xcodebuild exits 65 even when all failures use XCTExpectFailure. Add
the same expected-failure handling from the unit test step so browser
focus tests (which are expected to fail on headless runners) don't
break CI.
* Add virtual display for headless Depot runners
Depot macOS runners have no physical display, causing XCUITests to fail
with "Failed to activate application (current state: Running Background)".
This adds a small ObjC tool that creates a virtual display using the
private CGVirtualDisplay API before tests run.
* Split self-hosted concurrency groups per workflow
CI, nightly, and release all shared `self-hosted-build`, so the hourly
nightly cancelled in-progress CI runs. Now each workflow has its own
group (self-hosted-ci, self-hosted-nightly, self-hosted-release).
CI also gets cancel-in-progress: true so rapid pushes cancel stale runs.
After rm -rf of the SPM cache dir, recreate it as an empty directory
so binary target downloads (e.g. Sentry.xcframework.zip) don't hit
"already exists in file system" errors from stale artifacts on the
self-hosted runner.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Org policy now requires actions pinned to immutable SHAs instead of
mutable version tags. Pin actions/checkout, actions/github-script,
softprops/action-gh-release, and oven-sh/setup-bun across all workflows.
* Upgrade Sentry: tracing, breadcrumbs, dSYM upload
- Enhanced Sentry SDK init with performance tracing (10% sample),
explicit app hang timeout, stack trace attachment, and HTTP
failure capture
- Added breadcrumbs for key user actions: workspace switch/create/close,
split creation, command palette open/close, app focus — these give
context to hang/crash reports
- Added dSYM upload step to nightly and release CI workflows so hang
stacks are fully symbolicated (requires SENTRY_AUTH_TOKEN secret)
- Created SentryHelper.swift with lightweight breadcrumb helper
Closes https://github.com/manaflow-ai/cmux/issues/365
* Remove command palette breadcrumbs
Not useful for hang diagnosis — keep only workspace/tab/split/focus
breadcrumbs that correlate with heavy operations.
Remove -Dxcframework-target=native from CI and release workflows,
defaulting to universal (matching upstream ghostty). The native target
produces a macos-arm64 xcframework slice that causes Xcode to link the
final binary differently (~70KB more __text), resulting in menubar and
right-click lag on M1 Max. The arm64 static libraries are byte-for-byte
identical between native and universal builds - the difference is purely
in how Xcode resolves the xcframework slice.
The -Dxcframework-target flag controls platform slices (native=macOS
only, universal=macOS+iOS), not CPU microarchitecture. Removing it
caused CI to attempt iOS builds which fail due to missing Metal
iOS toolchain on the runner.
* Fix zsh git branch refresh race after cwd change
* Clarify intentional duplicate cwd check in git refresh path
* Add Metal Toolchain download step to CI and release workflows
Fixes build failure when compiling Metal shaders for iOS xcframework
targets — the self-hosted runner needs `xcodebuild -downloadComponent
MetalToolchain` installed before `xcrun metal` can run.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
The self-hosted runner (M4 Mac Mini) was building GhosttyKit with
-Dxcframework-target=native, producing M4-tuned binaries. This caused
menubar and right-click lag on M1 machines. Dropping the flag defaults
to universal, which works well across all Apple Silicon chips.
Hardened runtime's library validation was verifying every dylib on load,
causing noticeable UI lag. Add entitlements file with
disable-library-validation to fix while keeping notarization support.
hdiutil produces a basic layout. npm create-dmg (sindresorhus) gives
large centered icons with proper spacing. The blank Applications icon
is a macOS 26 rendering issue that affects both approaches.
create-dmg (brew) uses AppleScript/Finder for icon positioning which
times out on headless CI. Switch to hdiutil with Applications symlink
for reliable CI builds.
Switch from npm create-dmg (sindresorhus) to brew create-dmg
(create-dmg/create-dmg) which properly renders the Applications
folder symlink icon with explicit layout control.
* Fix zsh ZDOTDIR wrapper + log parsing with -- messages
* Fix CI race condition: serialize self-hosted builds with concurrency group
Two workflows racing on the same self-hosted runner caused DerivedData
corruption (release's rm -rf nuked DerivedData while CI was building).
Add shared concurrency group and scope DerivedData cleanup to project.
Root cause: INFOPLIST_KEY_ build setting prefix only works for Apple-recognized
keys (CF*, NS*, LS*), not custom keys like SUPublicEDKey. The key was never
being added to Info.plist, so generate_appcast silently skipped EdDSA signing
(no public key in app = nothing to match against).
Fix:
- Derive public key from private key at build time using CryptoKit
- Use PlistBuddy to inject SUPublicEDKey and SUFeedURL after build
- Add sign_update fallback in appcast script if generate_appcast skips signing
- Add base64 padding normalization for key handling
SPARKLE_PUBLIC_KEY was set as a shell env var but Xcode needs it passed
as a build setting argument. Without SUPublicEDKey in Info.plist, Sparkle
silently ignores updates.
