Repository navigation
Retry transient notarytool timeouts in package-release.sh #255
Description
Goal
Make scripts/package-release.sh survive transient notarytool network failures instead of failing the whole release run.
Context
During the v0.5.0 release (#252), notarytool requests to Apple intermittently failed with NSURLErrorDomain -1001 (request timed out) while plain HTTPS to the same endpoint stayed fast. notarize() runs notarytool submit --wait once and treats any non-JSON output as failure, so one timed-out poll aborts the run, leaves an orphaned (sometimes Accepted) submission, and costs the maintainer another pair of Ask Key approvals. Three runs failed this way before one succeeded.
Scope
scripts/package-release.sh and its tests or checks, if any. Keep the Ask Key delivery model (credential values only inside the helper's target shell, never printed), the four assets, and the stapling and verification steps unchanged.
Steps
- Split submission from waiting: submit once inside the Ask Key run, capture the submission ID, then poll status (
notarytool waitorinfo) with a bounded number of retries on transient network errors, inside the same delivered-credential run so no extra approval is needed. - Never resubmit automatically after a submission ID exists; on final failure, print the submission ID and the sanitized next step.
- Keep diagnostics free of signing identity, Team ID and key material.
Acceptance
bash -n and shellcheck (if available) pass; a synthetic --no-notarize packaging run still produces the same assets; the PR explains how a transient timeout is retried. Real notarization is verified at the next release.
Activity
luoji-bot commentedon Nov 3, 2026
Scope update from review round 1 on PR #256 (supersedes the original Scope and step 2 where they conflict):
scripts/package-release.sh, an optional runner file underscripts/that it calls by path,docs/testing.md(the release notarization description), and the automation tests and fixtures for them.notarytoolcall through an inherited pipe; it is never written elsewhere or printed.notarytool history(same artifact name, created after this submit started) and adopt that ID; only if none exists, resubmit, at most a small bounded number of times. Stop with a clear message on ambiguous matches or unavailable history. Print every submission ID obtained.luoji-bot commentedon Nov 3, 2026
Scope update from review round 2 on PR #256 (supersedes "one Ask Key approval per artifact" and the in-memory key pipe from the round-1 update):
notarytoolcannot read a key through a pipe (--key /dev/fd/Nfails with a file-permission error, checked on the maintainer's Mac with a non-release key). Credential mode therefore makes one Ask Key run pernotarytoolrequest (submit, history, status poll). Each run gets a freshly delivered key file used well within its 5-minute lifetime; the runner never reads the key itself.