patch-release.js: non-interactive mode (--yes, --cm-trigger, --json)

[kriszyp]

Motivation

The dispatch release-automation app runs patch-release.js headlessly from a dev-agent.
Two problems blocked that:

1. The script has four readline prompts that hang when stdin is a pipe or /dev/null.
2. Prompt 2 (CM deploy trigger) defaults YES on EOF — silently deploying to prod if
   the script exits early or is piped without input. This is a known footgun.

Changes

Three new flags; existing interactive behavior is unchanged when flags are absent.

--yes

Non-interactive mode. All prompts auto-answered:

• Prompt 1 (proceed with bump/tag/push): y
• Prompt 2 (CM deploy): n — opt-in only, see below
• Prompts 3/4 (return to original branches): y

The CM-deploy default is deliberately inverted from interactive mode. In interactive use,
pressing Enter (or EOF) triggers a deploy. In --yes mode the safe default is to skip the
deploy unless the caller explicitly opts in with --cm-trigger.

--cm-trigger

Triggers the CM release-to-environments workflow (step 6). With --yes: opt-in deploy.
Without --yes: skips prompt 2 and answers yes directly.

--json

Prints a final machine-readable line on stdout:

RESULT: {"ok":true,"target":"v5.1.27","coreVersion":null,"proVersion":"v5.1.27","coreBumped":false,"pushed":false,"cmTriggered":false,"dryRun":true}

Also emitted on fatal error paths before exit:

RESULT: {"ok":false,"error":"..."}

A die() helper consolidates the err()+JSON+process.exit() pattern that was scattered
across all error-exit sites.

Dry-run verification

node scripts/patch-release.js --dry-run --branch v5.1 --core-branch v5.1 --yes --json < /dev/null

Ran against the real repo: completed with no prompt hangs, no CM workflow triggered
(dry-run + no --cm-trigger), ended with a parseable RESULT line.

Output (abridged):

[dry-run] Skipping version bump, sync, and push.
  Skipped. Manually trigger release-to-environments with version_name=stable when ready.
✅ Done.
RESULT: {"ok":true,"target":"v5.1.27","coreVersion":null,"proVersion":"v5.1.27","coreBumped":false,"pushed":false,"cmTriggered":false,"dryRun":true}

🤖 Generated with Claude Code

[claude]

Reviewed; no blockers found.

[gemini-code-assist]

Code Review

This pull request adds non-interactive execution support to the patch-release.js script via new --yes, --cm-trigger, and --json flags, allowing for automated release flows and machine-readable JSON output. The feedback highlights two important improvements: first, using fs.writeSync instead of process.stdout.write in the die helper to ensure JSON output is fully flushed before process.exit terminates the process; second, safely handling caught exceptions in the global catch block to prevent secondary crashes when the error is not an instance of Error.

[kriszyp]

Pushed fixes for all 8 open threads (Gemini, cb1kenobi, and Kris's comments) in f782b1b:

• die()/success/abort RESULT writes now go through fs.writeSync(1, ...) instead of process.stdout.write(), fixing the truncation race with process.exit() on a piped stdout (Gemini, Kris — line 87/89).
• main().catch() no longer assumes the rejection is an Error (e?.message ?? String(e)) (Gemini).
• Declining the first confirmation prompt under --json now emits RESULT: {"ok":false,"error":"aborted","aborted":true} (exit 0) instead of exiting silently (Kris, cb1kenobi).
• A requested CM-trigger failure (--cm-trigger) is now terminal — nonzero exit, RESULT: {"ok":false,...} preserving pushed/version state — instead of being swallowed to stderr with ok:true (Kris, cb1kenobi).
• --cm-trigger without --yes no longer bypasses the deploy confirmation for an interactive human — it only changes the prompt's wording now; only --cm-trigger + --yes auto-confirms (cb1kenobi).

Extracted the decision logic (resolveDeployAnswer, buildAbortedResult, buildCmFailureResult, writeResult) into pure, exported functions with unit coverage in unitTests/scripts/patchRelease.test.mjs, since main() itself has no seams for testing without live git/gh state.

I ran this change through an independent pre-push review (Codex + Grok) across two rounds. One real regression it caught in round 1 — making the CM failure terminal via die() skipped Step 7's branch-restore, which would leave a reused dispatch worktree stuck on the release branch — is fixed in f782b1b. Round 2 confirmed no new issues from that fix.

One finding I'm flagging rather than fixing here (both Codex and Grok raised it, consistently across rounds): --yes auto-answers the first confirmation prompt (version bump/sync/tag/push) without any programmatic check that every patch-labeled PR actually has a corresponding release-branch commit — that verification is currently visual-only, and --yes skips the human who'd normally do it. A headless run could version/tag/push an incomplete release if a cherry-pick silently failed or is still queued. Fixing it properly needs a real design decision (how to match a cherry-picked commit back to its source PR — patch-id? cherry-pick trailer parsing?), so I didn't want to guess at it inside a review-feedback pass. Flagging for a follow-up if it's worth doing before --yes sees real dispatch use.

🤖 Generated by Claude Sonnet 5