Notarize by polling instead of a single --wait long-poll#12741
Closed
niksedk wants to merge 2 commits into
Closed
Conversation
The v5.1.0-rc13 release build sat on `notarytool submit --wait` until GitHub's 6-hour job limit killed both macOS jobs. The submissions themselves were Accepted within minutes (confirmed via `notarytool history`) - `--wait` is a single long-poll that hung after Apple had already returned a verdict, so the job blocked for six hours on a result it could have had at minute six. Submit once to capture the submission id, then poll `notarytool info` (short request/response calls) in a bounded 30-minute loop. A stuck long-poll can no longer block the job, and a transient poll failure retries on the next tick instead of tripping the step's `set -e`. Also runs `notarytool log` on a non-Accepted result: the previous workflow failed blind on rejection, printing nothing from Apple. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the macOS release packaging workflow to avoid xcrun notarytool submit --wait long-poll hangs by switching to a bounded polling approach, improving reliability of notarization within GitHub Actions’ job time limits.
Changes:
- Replaces
notarytool submit --waitwithsubmit(capture submission id) + periodicnotarytool infopolling (30-minute ceiling). - Makes polling resilient to transient
infofailures to avoid failing the job due to a single request error. - Adds
notarytool logoutput on non-Acceptedstatuses to surface Apple’s rejection details.
The 30-minute poll loop can exit with status still "In Progress". That path previously reported a generic "did not succeed" and ran `notarytool log`, which has nothing for an incomplete submission - reading like a rejection when it is a timeout. Handle "In Progress" as its own case with a clear message and no log fetch. (Copilot review feedback) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The first signed release build (v5.1.0-rc13, run 29934529671) had both macOS jobs killed at GitHub's 6-hour limit, stuck on:
notarytool historyafterwards showed both DMGs wereAcceptedwithin minutes of submission:So notarization succeeded —
--wait, a single long-poll, hung for six hours on a verdict Apple had already returned.Fix
Submit once to capture the submission id, then poll
notarytool info(short request/response calls) in a bounded 30-minute loop. A stuck long-poll can no longer block the job.In Progressand retry next tick, rather than tripping the step'sset -e.Acceptedresult now runsnotarytool logto surface Apple's reasons — the previous workflow printed nothing on rejection.YAML validated; JSON parsing tested against the real
submit/infooutput shapes.🤖 Generated with Claude Code