ci(mac-release): release-contract asserts scheme + bundle-id + SUPublicEDKey#807
Conversation
…icEDKey The "Verify release contract" step previously only checked that the Xcode project + Info.plist + Sparkle script paths exist. A rename inside the owletto submodule (scheme Lobu->Owletto, bundle id ai.lobu.mac->ai.owletto.mac, Sparkle key removal) would pass those checks and fail late in xcodebuild, or worse, silently break auto-update for installed users. Add four assertions in the same shell block: - xcodebuild -list must expose a scheme named exactly 'Lobu' (the workflow uses `-scheme Lobu` everywhere). - Info.plist CFBundleName and CFBundleDisplayName must be 'Owletto'. - project.pbxproj must still set PRODUCT_BUNDLE_IDENTIFIER = ai.lobu.mac (CFBundleIdentifier in Info.plist resolves to that var at build time, so the real id lives in the pbxproj build settings). - Info.plist must contain <key>SUPublicEDKey</key> so installed apps can verify Sparkle update signatures. Backward-compatible: only adds checks. Closes #794.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe PR tightens the macOS release workflow by adding explicit, fail-fast checks that the Xcode scheme ChangesmacOS Release Contract Validation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![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: 29fba826ba
ℹ️ 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".
| if ! grep -q "PRODUCT_BUNDLE_IDENTIFIER = ${EXPECTED_BUNDLE_ID};" \ | ||
| packages/web/apps/mac/Lobu.xcodeproj/project.pbxproj; then |
There was a problem hiding this comment.
This grep passes as soon as any build setting in project.pbxproj still contains ai.lobu.mac, but Xcode projects commonly have separate Debug/Release settings (and possibly test targets). If the app's Release configuration drifts to ai.owletto.mac while another configuration still has the old value, this check succeeds and the later Archive steps still build -configuration Release, so the release can ship with the wrong bundle id despite the contract check.
Useful? React with 👍 / 👎.
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Pi review on PR #807 flagged three checks that could pass while the release contract was actually broken: 1. Scheme check matched against `xcodebuild -list` plain output, which contains both a `Targets:` and a `Schemes:` section. A target named 'Lobu' would satisfy the grep even if the scheme had been renamed to 'Owletto'. Switch to `-list -json` and parse the schemes array, so only an actual scheme named 'Lobu' counts. 2. PRODUCT_BUNDLE_IDENTIFIER grep proved "some occurrence equals ai.lobu.mac". If one build config drifted while another stale occurrence stayed correct, the grep would still pass. Assert the distinct set of values across project.pbxproj equals exactly {ai.lobu.mac}. 3. SUPublicEDKey grep could match the literal string inside an XML comment. Replace with PlistBuddy `Print :SUPublicEDKey`, which only succeeds when it's an actual plist key. Sanity-checked all three against the currently pinned submodule SHA (b01682708) locally: scheme list = "Lobu", distinct bundle ids = "ai.lobu.mac", PlistBuddy returns the key. No behavior change beyond catching cases the old checks would silently miss.
2 participants
Closes #794.
Context
PR #784 added a "Verify release contract" step in
mac-release.ymlthat only checked path existence. A rename inside thelobu-ai/owlettosubmodule (Xcode schemeLobu→Owletto, bundle idai.lobu.mac→ai.owletto.mac, or accidental removal ofSUPublicEDKey) would pass those checks and fail late inxcodebuild -scheme Lobu— or worse, silently break Sparkle auto-update for installed users.What's now verified
The same
Verify release contractshell block (no new step) now also asserts, at the pinned submodule SHA, before any build runs:xcodebuild -project Lobu.xcodeproj -listexposes a scheme named exactlyLobu(regex-anchored so e.g.LobuTestsdoesn't match).Info.plistCFBundleNameandCFBundleDisplayNameare bothOwletto(what users see in Finder, the menu bar, "About").project.pbxprojstill setsPRODUCT_BUNDLE_IDENTIFIER = ai.lobu.mac—CFBundleIdentifierin Info.plist resolves to$(PRODUCT_BUNDLE_IDENTIFIER)at build time, so the real id lives in the pbxproj build settings. This is the value the URL scheme, Keychain service name, and Sparkle update path all key off.Info.plistcontains<key>SUPublicEDKey</key>so installed apps can still verify Sparkle update signatures.Compatibility
Additive only — every existing path-existence check is preserved unchanged. Verified locally against the currently-pinned
packages/webSHA: all four new assertions pass; flipping any of the four expected values to a renamed variant (Owlettoscheme,ai.owletto.macbundle id) fails with a clear::error::and aborts beforexcodebuildruns.Summary by CodeRabbit