Release pipeline: signed macOS DMG, Windows installer, Linux tarball - #6
Open
pob31 wants to merge 2 commits into
Open
Release pipeline: signed macOS DMG, Windows installer, Linux tarball#6pob31 wants to merge 2 commits into
pob31 wants to merge 2 commits into
Conversation
The POST_BUILD steps staged Resources/lang and Resources/SOFA into $<TARGET_FILE_DIR:XOA>, which inside an .app is Contents/MacOS. That is wrong twice over. codesign treats Contents/MacOS as CODE, so `codesign --verify --strict` fails with "code object is not signed at all" on every staged data file, and the notary rejects the build. Found while validating the release signing path locally. Worse, LocalizationManager has always resolved its macOS resource dir as currentApplicationFile/Contents/Resources — which nothing populated. The macOS app has been running with no translations at all; only the dev-tree fallback in XoaMonitoringEngine kept the bundled HRTF set reachable. Stage into Contents/Resources on Apple and beside the binary elsewhere, and make builtInSofaFile() mirror the same split. The staging location is now an invariant shared by three places, so record it in CLAUDE.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… a tarball Closes the packaging half of WP14 (decision record D55). A published GitHub Release — or a manual dispatch against a tag — builds and attaches: macOS XOA-v<version>-macos-arm64.dmg signed, notarized, stapled Windows XOA-<tag>-windows-x64-Setup.exe unsigned Inno Setup installer Linux XOA-<tag>-linux-x86_64.tar.gz install.sh / uninstall.sh The packaging logic lives in scripts rather than in the workflow YAML, so every lane runs identically on a developer machine: tools/ci/build-macos-release.sh + release-entitlements.plist tools/linux/build-app-tarball.sh Installer/XOA-Installer.iss Notable choices, all recorded in D55 and Documentation/XOA-RELEASE.md: - DMG, not the .pkg the devplan originally called for: drag-to-Applications needs only the Developer ID Application identity, so the release carries one signing credential instead of two. - project(XOA VERSION ...) is the single source of truth; a verify-version job refuses a tag that disagrees before spending build minutes. - arm64 only. ARCHS="arm64;x86_64" still yields a universal DMG on demand. - The signing secrets live in the protected `xoa` environment, not at repo level — this repo is public, and the environment's reviewer rule is the boundary that keeps the Developer ID key away from untrusted refs. Every release therefore pauses for a manual approval. - A dry_run dispatch input packages every lane into workflow artifacts without touching a Release, so the pipeline can be proven before there is a v1 to cut. The app is not finished; this is how it gets exercised. - The head-tracker plugin ships on Windows only. macOS/Linux would need WFS-DIY's static WFS_HEADTRACK_BUNDLED_OPENCV build ported into tools/headtrack. The Windows step is continue-on-error and the .iss marks the plugin files skipifsourcedoesntexist, so a break there degrades the installer instead of blocking the release; the job summary says which. - assets/linux/70-xoa.rules (Stream Deck+ / SpaceMouse hidraw access) ships ahead of the controller support itself. The rules only relax device permissions, so they are inert until that work lands and the packaging will not need revisiting when it does. tools/ci/set-macos-cert-secret.sh verifies a .p12 really holds a Developer ID Application certificate AND its private key, then sets MACOS_CERT_P12_BASE64 and MACOS_CERT_PASSWORD together — a mismatch between those two only surfaces inside the signing job, minutes into a build. Validated locally on macOS: Release arm64 build, hardened-runtime sign (entitlements verified, get-task-allow false), strict codesign verify, DMG built and signed, and the signed bundle passes --gui-smoke. Notarization and the Windows/Linux lanes are still unexercised. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sets up WP14's packaging half (decision record D55). Nothing here cuts a release — it makes one possible, and adds a dry-run path so the pipeline can be proven while the app is still unfinished.
What a tagged release produces
XOA-v<version>-macos-arm64.dmgXOA-<tag>-windows-x64-Setup.exeXOA-<tag>-linux-x86_64.tar.gzinstall.sh/uninstall.shPackaging logic lives in scripts, not in the YAML, so each lane runs identically on a dev machine:
tools/ci/build-macos-release.sh,tools/linux/build-app-tarball.sh,Installer/XOA-Installer.iss.The bug this shook out
The first local signing run failed:
Contents/MacOSis the directory codesign treats as code, so every staged data file there fails--verify --strictand the notary rejects the build.Chasing it surfaced a second, pre-existing bug:
LocalizationManager::getResourceDirectory()has always resolved the macOS resource dir ascurrentApplicationFile/Contents/Resources— which nothing populated. The macOS app has been running with no translations. OnlyXoaMonitoringEngine's dev-tree fallback kept the bundled HRTF set reachable.Fixed in the first commit; three places now agree (CMake POST_BUILD,
LocalizationManager,builtInSofaFile()), and the invariant is recorded in CLAUDE.md because it is easy to drift.Choices worth reviewing
.pkgthe devplan originally specified — needs only the Developer ID Application identity, so one signing credential instead of two.ARCHS="arm64;x86_64"still yields a universal DMG on demand.xoaenvironment, not at repo level. This repo is public; the environment's reviewer rule is the boundary keeping the Developer ID key away from untrusted refs. Consequence: every release pauses for a manual approval.WFS_HEADTRACK_BUNDLED_OPENCVbuild ported intotools/headtrack. The Windows step iscontinue-on-errorand the.issmarks plugin filesskipifsourcedoesntexist, so a break degrades the installer rather than blocking the release.assets/linux/70-xoa.rulescovers Stream Deck+ and SpaceMouse; they only relax device permissions, so they are inert until that support lands and packaging won't need revisiting.Verified
Locally on macOS: Release arm64 build → hardened-runtime sign (entitlements confirmed,
get-task-allowfalse) → strict codesign verify → signed 17 MB DMG; the signed bundle passes--gui-smoke.Not verified: notarization itself, and the Windows/Linux lanes. Use Run workflow with
dry_runticked andtagempty to exercise all three (including the notary round-trip and the approval flow) without touching a Release.Unrelated finding
cteston a Release build failstests/XoaRotationTests.cpp:523— the in-place-vs-separate-buffer rotation aliasing guard, at 1e-15. CI only ever builds Debug, so Release optimization/FP settings appear to letrot::applydiverge between the two call sites. Not touched here; flagged for a separate look.🤖 Generated with Claude Code