ci: allow development-signed releases#25
Conversation
Signed-off-by: Sertac Ozercan <sozercan@gmail.com>
There was a problem hiding this comment.
Pull request overview
Enables public releases signed with Apple Development certificates while preserving Developer ID notarization.
Changes:
- Allows Apple Development signing for published releases.
- Prevents ad-hoc signing and validates team IDs.
- Restricts notarization to Developer ID builds.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/release.yml |
Updates release signing selection and verification. |
Review details
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Medium
| if [ -n "$APPLE_DEVELOPMENT" ]; then | ||
| echo "::add-mask::$APPLE_DEVELOPMENT" | ||
| echo "::warning::Using Apple Development signing; this build will not be notarized." | ||
| echo "::warning::Using Apple Development signing; this release will not be notarized." |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1667dc26b0
ℹ️ 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".
| APPLE_DEVELOPMENT=$(security find-identity -v -p codesigning "$KEYCHAIN_PATH" 2>/dev/null \ | ||
| | awk '/Apple Development/ { print $2; exit }' || true) | ||
| if [ -n "$APPLE_DEVELOPMENT" ] && [ "$REQUIRE_DEVELOPER_ID" != "true" ]; then | ||
| if [ -n "$APPLE_DEVELOPMENT" ]; then |
There was a problem hiding this comment.
When APPLE_TEAM_ID is set (mandatory for push/publish releases) and the imported PKCS#12 contains multiple Apple Development identities, the security find-identity pipeline above keeps the first one and this changed condition accepts it without checking the team. The later TeamIdentifier validation then fails after the full build even if a matching development identity exists later in the same keychain, so release success depends on export order; filter Apple Development identities by EXPECTED_TEAM_ID like the Developer ID path.
Useful? React with 👍 / 👎.
| if [ -n "$APPLE_DEVELOPMENT" ]; then | ||
| echo "::add-mask::$APPLE_DEVELOPMENT" | ||
| echo "::warning::Using Apple Development signing; this build will not be notarized." | ||
| echo "::warning::Using Apple Development signing; this release will not be notarized." |
There was a problem hiding this comment.
When this branch is taken for a tag push or publish=true run, the workflow now continues to the GitHub release and stable Homebrew cask publishing steps even though the artifact is only Apple Development-signed and explicitly not notarized. Apple’s distribution guidance says Mac apps distributed outside the Mac App Store need Developer ID signing/notarization for Gatekeeper, so this scenario publishes a ZIP that normal Homebrew/GitHub users cannot launch without disabling Gatekeeper; keep Apple Development signing limited to non-published validation builds or do not publish the cask/release from this path. See https://help.apple.com/xcode/mac/current/en.lproj/dev033e997ca.html
Useful? React with 👍 / 👎.
Summary
APPLE_TEAM_IDWhy
The project does not have a paid Apple Developer Program account, so public releases need to use the available Apple Development certificate instead of Developer ID signing.
Validation
./scripts/test.shactionlint .github/workflows/release.ymlarm64/x86_64Release build with version2.0.0TeamIdentifier=57QNR9B89Qand Finder automation entitlement