-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v3] Bundling/signing #4171
base: v3-alpha
Are you sure you want to change the base?
[v3] Bundling/signing #4171
Conversation
WalkthroughThis pull request updates the macOS build and run processes by enhancing the Taskfile for asset building. The production bundle is now explicitly signed using codesign after file copying, and a new development bundle is created with its own structure, including an Info.plist file, icon, and executable—all signed using codesign. Additionally, documentation is updated to reflect these changes in both the changelog and the macOS build feature sections. Changes
Sequence Diagram(s)sequenceDiagram
participant Builder as Build System
participant Bundler as App Bundler
participant CodeSigner as Code Signer
participant Executor as App Executor
Builder->>Bundler: Copy files for production bundle
Bundler->>CodeSigner: Execute codesign for production bundle
CodeSigner->>Bundler: Return signed bundle
Builder->>Bundler: Create development bundle directory
Bundler->>Bundler: Copy icon, executable, and Info.plist for dev bundle
Bundler->>CodeSigner: Execute codesign for development bundle
CodeSigner->>Bundler: Return signed dev bundle
Builder->>Executor: Execute development bundle
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
docs/src/content/docs/changelog.mdx (1)
142-143
: Clarify the Changelog Entry for Ad-hoc Signing
The entry “Creates and ad-hoc signs app bundles in dev to enable certain macOS APIs” is concise. Consider adding a brief note or a reference to the documentation for further clarification on the limitations (e.g., that ad-hoc signing is only suitable for development, not for app distribution) to guide users appropriately.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
docs/src/content/docs/changelog.mdx
(1 hunks)docs/src/content/docs/guides/signing.mdx
(1 hunks)docs/src/content/docs/learn/build.mdx
(1 hunks)
🔇 Additional comments (2)
docs/src/content/docs/guides/signing.mdx (1)
87-99
: Ensure the Updated Notarization Source Path is Consistent
Thegon-sign.json
snippet now uses"source": ["./build/bin/release/app"]
, which aligns with the new release directory structure for notarization. Please verify that this change is intentional and that all related build and notarization scripts expect the binary to be in this location.docs/src/content/docs/learn/build.mdx (1)
123-127
: Acknowledge the Addition of Ad-hoc Signing in the macOS Build Process
The macOS section now includes “Ad-hoc signing.app
bundles,” which reflects the new capability in the build system. Ensure that related documentation (e.g., in the signing guide) details when and why you would use ad-hoc signing versus proper distribution signing. Overall, this update enhances clarity on the build process.
Thanks so much for opening this (and being patient!). I'm wondering, for compatibility reasons, whether we leave releases as they currently are but alter the dev output to be |
Sure if compatibility here is key, I don't have a strong reason to change the structure we have, just preference. On my own projects I might just separate it out, my brain will like that 😅 I'll change it later today (PST). Thanks! |
Thank you! There's a level of inertia we need to consider 😅 |
|
Description
This PR makes changes to the macOS build tasks to bundle and sign Wails binaries to enable new macOS APIs.
Upcoming Notifications API (#4098) on macOS requires the app to be bundled with a bundle identifier and signed to work properly.
Fixes (#4098)
Changes
dev
build
package
.dev
appended.build
binary frombin
, dev bundle identifier frombuild/darwin/Info.dev.plist
, and the icons frombuild/darwin/icons.icns
.It will be important to document that the ad-hoc signing will not work for distributing the app and is only sufficient for local testing/use. Signing and notarizing is required for distribution.
Type of change
Please select the option that is relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration using
wails doctor
.If you checked Linux, please specify the distro and version.
Test Configuration
Please paste the output of
wails doctor
. If you are unable to run this command, please describe your environment in as much detail as possible.Checklist:
website/src/pages/changelog.mdx
with details of this PRSummary by CodeRabbit
New Features
Documentation