andreagrandi / andreagrandi/draftomen
Publish an Intel (x86_64) macOS bundle alongside the arm64 bundle
- 主要言語
- Python
- スター
- 0
- フォーク
- 0
- 平均マージ
- 1時間 23分
- マージ済み PR(30日)
- 181
説明
## Problem
The native macOS DMG is built on `macos-latest`, which GitHub now maps to an arm64 image. Nuitka compiles for the host architecture and the uv-managed Python is single-arch, so the published `Draftomen-unsigned-macos.app` runs only on Apple Silicon even though the PySide6 6.11.2 wheels are universal2. Users on Intel Macs cannot launch the downloaded application at all; their only workaround is the PyPI or Homebrew install.
## Proposed change
Add a second macOS job to `.github/workflows/native-bundles.yml` that builds the same spec natively on a GitHub Intel runner (`macos-15-intel`), smoke-tests the mounted DMG there, and publishes an x86_64 DMG next to the arm64 one in both the rolling development prerelease and tagged releases. Each macOS job verifies the built executable's architecture explicitly instead of inheriting it from the runner. Because the current asset name carries no architecture, rename the macOS assets to `draftomen--unsigned-macos-arm64.dmg` and `draftomen--unsigned-macos-x86_64.dmg`, and update every consumer of that name: the release and development publish steps, the checksums file, the website download links and release-output check, the development-release skill's asset assertion, and the bundle and release docs.
Do not use Nuitka's universal target: it needs a universal2 interpreter that uv does not provide and doubles the download size. Signing and notarization remain in #126, which will sign both architectures.
## Acceptance Criteria
- [ ] AC1: The native-bundles matrix contains an `x86_64` macOS entry on `macos-15-intel` and an `arm64` entry on the existing arm64 runner, both using `pysidedeploy.macos.spec`, verified by a workflow-configuration test in `tests/test_desktop_bundle.py`.
- [ ] AC2: Each macOS job runs an architecture check (`lipo -archs` on the `CFBundleExecutable`) that fails the job when the result differs from the matrix architecture, verified by inspecting a failing and a passing workflow run.
- [ ] AC3: The Intel job mounts its DMG and passes `tests/bundle_smoke.py` natively, verified by the workflow run log.
- [ ] AC4: The rolling development prerelease publishes exactly four assets: the arm64 DMG, the x86_64 DMG, the Windows executable, and a SHA-256 file listing all three binaries, verified by the development-release skill's asset assertion.
- [ ] AC5: The tagged release job publishes the same four assets with tag-based names, verified by `tests/test_desktop_bundle.py` asserting the release workflow's asset names.
- [ ] AC6: The website landing page offers both macOS downloads and `website/scripts/check-release-output.mjs` requires both URLs, verified by `npm run build --prefix website` followed by the check script.
- [ ] AC7: `docs/desktop-bundles.md` and `docs/releasing.md` document both architectures, the runner labels, the asset rename, and that Intel support tracks GitHub Intel runner availability, and `CHANGELOG.md` has an Unreleased entry.
- [ ] AC8: A manual `workflow_dispatch` run publishes the development prerelease with both DMGs, and the x86_64 DMG launches on an Intel Mac or, failing that, under Rosetta 2 with `arch` confirming an `i386` process.
## Dependencies
None. Follow-up: #126 signs and notarizes both architectures once this ticket lands.
## Implementation classification
- **Estimated size:** M
- **Orchestration risk:** Normal
- **Reason:** One release-pipeline outcome across two workflows plus small doc, website, and skill updates, with no runtime code change.
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
評価
この issue はまだ評価されていません。