Repository navigation
Notify Homebrew users when updates are available - #4327
Yuxin-Qiao wants to merge 7 commits into
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs real behavior proof before merge. Reviewed October 8, 2026, 5:35 AM ET / 09:35 UTC (Revision 7). ClawSweeper reviewWhat this changesThe branch adds silent Homebrew update notifications, remembers submitted versions across restarts, and opens Settings → About when a notification is clicked. Example: An automatic check finds synthetic version 99.0.5
Review scores
ProductKind: Feature · Worth it: Yes Merge readiness⛔ Blocked before merge - 2 items remain This PR needs real behavior proof before merge. The useful, owner-supported change is absent from current main; no concrete patch defect was found, but the previously identified native interaction gap remains. Likely related people: steipete and Yuxin-Qiao, both high-confidence routing candidates from merged updater and notification history. Priority: P3 Before merge
FindingsNone. Tests
Agent review detailsHow this fits togetherCodexBar’s Homebrew updater reads the tap’s available version and offers installation through the existing Homebrew command path. This change sends automatic-check results through macOS notifications and routes clicks back to About. flowchart TD
A[Startup or daily check] --> B[Read Homebrew tap version]
B --> C{New version and automatic checks enabled?}
C -->|Yes| D[Remember and deduplicate notices]
D --> E[Silent macOS notification]
E -->|User clicks| F[Settings About]
F -->|User chooses update| G[Existing Homebrew installation path]
Technical reviewBest possible solution: Keep notification discovery attached to the existing Homebrew updater, with installation remaining an explicit action in About. Do we have a high-confidence way to reproduce the issue? Not applicable to a feature request; current main confirms that Homebrew updates are exposed through the menu and About without this native notification path. Is this the best way to solve the issue? Yes: extending the existing updater and shared notification sender preserves Homebrew ownership and avoids a competing installation path. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 08eb56931c8e. Provenance checked
TestingProof path: in-process harness. Added test files: 3. SecurityNone. EvidenceWhat I checked:
Likely related people:
Review metrics
LabelsLabel changes: No label changes. Label justifications:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment HistoryReview history (6 earlier review cycles)
|
Retain the contributor notification feature and synchronize current main. Recheck the automatic-check preference before fetching, retire saved notices when starting with checks disabled, and keep manual checks available. Add regression coverage and document the preference behavior. Refs steipete#4327 Co-authored-by: Yuxin Qiao <104957188+Yuxin-Qiao@users.noreply.github.com>
Merge origin/main at 844b0e1 to include the current cost-storage changes and CI gate. Preserve the contributor notification feature and its documented native-proof limitations.
With a Homebrew installation and automatic checks enabled, a newer tap version currently appears only in the menu and Settings → About. Users have to open one of those surfaces to discover the update.
Send a silent macOS notification when a startup or daily check finds a newer installable tap version. Clicking it opens Settings → About to review and install the update. This follows up on #3994 and keeps installation in the existing Homebrew updater.
Validation
The current integrated production revision is
1607c1a189ca2c990794fd4f03efa11129767ca5, merging main08eb56931. The 24 append-only conflicts in CHANGELOG and 23 localization catalogs preserve both sides. Catalog reconciliation confirms every upstream entry and each PR notification body, without duplicate keys. The notification implementation and click handler were unchanged by the synchronization. See the integrated validation receipt and the earlier validation receipt.make checkpassed with zero violations in 2,871 Swift files.Scripts/test.shrunner used four direct workers, a 600-second group timeout, and a native SwiftPM forwarding wrapper (--jobs 4 -Xswiftc -gnone). The earlier serial fallback was interrupted and is not counted as a pass.54ada0fe3,make test-fast FILTER='HomebrewUpdateNotifierTests|HomebrewUpdaterControllerTests|UpdateNotificationActionTests|SparkleUpdaterControllerTests|LocalizationBundleTests|CredentialNotificationTests|CostUsageCodexRowStorageTests|CostUsageClaudeRowStorageTests|CostUsageCoverageCompatibilityTests'passed: 61 tests in nine suites.c16e1a6f7passed through the documented./Scripts/test.sh --direct-workers 4: verified 14,081 methods, selected all 1,593 selections, 144/144 groups passed first attempt, zero retries or timeouts.54ada0fe3: 67 Swift Testing tests in nine suites plus three XCTest tests; and a native-backend direct full run verifying 14,084 methods, selecting all 1,595 selections, 144/144 groups passed first attempt, zero retries, timeouts or failed groups. It used a forwarding wrapper with--build-system native --jobs 4 -Xswiftc -gnoneand a 600-second group timeout. These maintainer-recorded results are retained separately from this follow-up's directly observed local runs.All six production notification and settings-route source hashes are identical between
c16e1a6f7and54ada0fe3. Among those receipt-listed files, the current main synchronization changes only the About Website destination. Archived native captures and their source-identity report still attest54ada0fe3; the sender, delegate, updater, app entry and settings controller match the current integrated revision. The earlier build receipt and current build receipt identify their respective signed fixture executables.Native runtime evidence — partial
The reproducible fixture and evidence use a freshly rebuilt full CodexBar executable from
54ada0fe3in an isolated, ad-hoc signed app, passing strict signature verification. It sends through the production notifier,AppNotifications.shared, and realUNUserNotificationCenter, with the real production notification delegate installed. Synthetic cask versions and contained provider stores avoid account and credential access. The fixture never runs an actual Homebrew upgrade and does not inject notification response callbacks. The receipts specify the local signing and startup instrumentation boundaries.The native events, UI transcript, verification report, and interaction record distinguish system diagnostics from UI observations. Manual settings opens are explicitly excluded from notification-click proof.
99.0.1through99.0.5requests as delivered and silent.99.0.1version, ran its startup check, and did not submit that version again.99.0.5to prepare this step.Actual preference screenshots: enabled, turned off, and still off after restart. These contain synthetic data and disabled providers only.
The maintainer has marked the PR ready for review. Native notification-click evidence and required remote macOS CI remain outstanding. Notification permissions and Focus settings govern visible presentation. Local test completion and native delivery receipts do not establish approval or merge.