Add Intel macOS artifacts to Tauri release matrix#215
Conversation
The release workflow only produced Apple Silicon macOS packages, so Intel users had no official GitHub Release artifact. Extend the matrix with an x86_64 macOS lane and align artifact naming and updater-manifest paths with per-arch outputs. Constraint: Keep existing release pipeline shape and signing flow unchanged Rejected: Split Intel build into separate workflow file | higher maintenance and duplicated logic Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep macOS conditions architecture-agnostic so new mac runners are not skipped accidentally Tested: YAML syntax parse via python yaml.safe_load; workflow diff reviewed for mac gating/artifact paths Not-tested: Full GitHub Actions matrix run on tag push
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fbcddc40db
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - platform: macos-13 | ||
| rust-target: x86_64-apple-darwin | ||
| updater-target: darwin | ||
| updater-arch: x86_64 |
There was a problem hiding this comment.
Disambiguate macOS updater bundle filenames by architecture
Adding the new macos-13 lane creates two macOS jobs that each publish macos/*.app.tar.gz under the same asset name (OpenLess.app.tar.gz). In this workflow, each matrix job calls softprops/action-gh-release@v2, which overwrites same-named assets by default, so whichever macOS job finishes last replaces the other binary. Because write-updater-manifest.mjs derives each per-arch manifest URL from basename(artifact) (macos/OpenLess.app.tar.gz), both latest-darwin-aarch64.json and latest-darwin-x86_64.json can point to the same release asset, causing one architecture to download the wrong bundle/signature pair.
Useful? React with 👍 / 👎.
PR Reviewer Guide 🔍(Review updated until commit c8ccff0)Here are some key observations to aid the review process:
|
Intel and Apple Silicon macOS jobs produced the same updater bundle filename, which let one matrix job overwrite the other release asset and could point both architecture manifests to a single binary. Rename macOS updater bundles per architecture before release upload and prefer arch-specific artifact lookup when generating updater manifests. Constraint: Keep existing updater manifest format and release action usage Rejected: Split macOS uploads into separate release jobs | larger workflow churn Confidence: high Scope-risk: narrow Reversibility: clean Directive: Any new macOS updater lane must keep unique asset names to preserve manifest correctness Tested: release-tauri.yml YAML parse; diff audit for rename+manifest path alignment Not-tested: End-to-end tagged GitHub Actions release run
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
|
Persistent review updated to latest commit c8ccff0 |
User description
The release workflow only produced Apple Silicon macOS packages, so Intel users had no official GitHub Release artifact. Extend the matrix with an x86_64 macOS lane and align artifact naming and updater-manifest paths with per-arch outputs.
Constraint: Keep existing release pipeline shape and signing flow unchanged
Rejected: Split Intel build into separate workflow file | higher maintenance and duplicated logic
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep macOS conditions architecture-agnostic so new mac runners are not skipped accidentally
Tested: YAML syntax parse via python yaml.safe_load; workflow diff reviewed for mac gating/artifact paths
Not-tested: Full GitHub Actions matrix run on tag push
PR Type
Enhancement
Description
Add Intel macOS (x86_64) matrix lane to release workflow
Make macOS-specific conditions architecture-agnostic (startsWith)
Disambiguate updater bundle filenames per architecture
Update updater manifest script to prefer arch-specific bundle
Diagram Walkthrough
flowchart LR R["Release Workflow"] -- "Add Intel macOS matrix" --> M["macOS-13 (x86_64)"] R -- "Generic macOS conditions" --> C["startsWith(platform,'macos')"] M -- "Rename updater bundle" --> U["OpenLess_{arch}.app.tar.gz"] U -- "Update manifest paths" --> P["latest-darwin-x86_64.json"] S["Manifest Script"] -- "Prefer arch-specific" --> D["macos/OpenLess_x86_64.app.tar.gz"]File Walkthrough
release-tauri.yml
Add Intel macOS build lane and arch-agnostic conditions.github/workflows/release-tauri.yml
== 'macos-latest'withstartsWith(platform,'macos')for future compatibilitycollisions
of hardcoded aarch64
write-updater-manifest.mjs
Prefer arch-specific updater bundle in manifest scriptopenless-all/app/scripts/write-updater-manifest.mjs
to generic bundle