Improve release-task dry-run UX and AUTO_CONFIRM docs

[justin808]

Summary

• add explicit dry-run messaging when confirmation prompts are skipped in create_release
• print the would-run GitHub release CLI command during dry-run release sync
• refactor GitHub release command construction into a helper for consistency
• document AUTO_CONFIRM=true usage in docs/releasing.md and note dry-run prompt behavior

Testing

• bundle exec rubocop rakelib/release.rake
• yarn prettier --check docs/releasing.md

Refs #947.

---

Note

Low Risk
Low risk: changes are limited to release tooling UX and documentation, with no runtime application behavior impact. The main risk is minor confusion if the new dry-run messaging or gh command preview is incorrect.

Overview
Improves the release rake tasks’ dry-run UX by emitting explicit messages when confirmation prompts are skipped and by printing the exact gh release command that would run when syncing GitHub releases.

Refactors GitHub release command construction into a shared github_release_command helper for consistent create/edit behavior, and updates docs/releasing.md to document AUTO_CONFIRM=true for non-interactive maintainer runs and note the enhanced dry-run output.

^{Written by Cursor Bugbot for commit 0aedeee. Configure here.}

[coderabbitai]

Warning

Rate limit exceeded

@justin808 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 7 minutes and 25 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 7c572ee5-ff60-4ba0-912c-d7391e1b588c

📥 Commits

Reviewing files that changed from the base of the PR and between b259a0e and b9a3b12.

📒 Files selected for processing (2)

• docs/releasing.md
• rakelib/release.rake

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch jg-codex/issue-947-release-dry-run-ux

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR improves the dry-run experience for Shakapacker's release tasks by adding explicit "skipping confirmation" messages when prompts are bypassed during dry-run, printing the would-run gh CLI command during dry-run release sync, and documenting the AUTO_CONFIRM=true environment variable in docs/releasing.md.

• Extracted github_release_command helper from publish_or_update_github_release for reuse in both dry-run preview and actual execution paths
• Added DRY RUN: Skipping confirmation prompt... messages at both confirmation points in create_release (CHANGELOG.md version and patch release)
• Dry-run of sync_github_release now displays the exact gh release create/edit command that would be executed
• docs/releasing.md updated with AUTO_CONFIRM=true usage example and dry-run behavior notes
• Minor behavioral change: dry-run path now probes gh release view to determine create vs. edit, which was previously only done in the non-dry-run path

Confidence Score: 4/5

• This PR is safe to merge — it only adds informational output and documentation, with no changes to the actual release publishing logic.
• The changes are low-risk: dry-run messaging improvements, documentation additions, and a clean refactor of command construction. The only notable change is a new gh release view API call in the dry-run path, which is a minor behavioral change but not a correctness issue. No publishing logic was modified.
• No files require special attention. The rakelib/release.rake refactor is clean and the docs/releasing.md changes are accurate.

Important Files Changed

Filename	Overview
rakelib/release.rake	Refactors GitHub release command construction into a reusable helper and adds dry-run messaging. The extracted helper introduces a real gh release view API call in the dry-run path (previously avoided), which is a minor behavioral change. Otherwise clean and consistent.
docs/releasing.md	Documents AUTO_CONFIRM=true usage and dry-run behavior improvements. Changes are accurate and consistent with the code.

Sequence Diagram

sequenceDiagram
    participant User
    participant create_release as create_release task
    participant confirm as confirm_or_abort!
    participant publish as publish_or_update_github_release
    participant gh_cmd as github_release_command (new helper)
    participant GitHub as GitHub API

    User->>create_release: rake create_release[...,true]
    
    alt CHANGELOG version found (dry_run=true)
        create_release->>create_release: puts "DRY RUN: Skipping confirmation prompt..."
        Note right of create_release: Previously called confirm_or_abort!
    end

    alt patch version fallback (dry_run=true)
        create_release->>create_release: puts "DRY RUN: Skipping confirmation prompt..."
    end

    create_release->>publish: publish_or_update_github_release(dry_run: true)
    publish->>gh_cmd: github_release_command(notes_file_path: "<release-notes-file>")
    gh_cmd->>GitHub: gh release view (new API call in dry-run)
    GitHub-->>gh_cmd: exists? true/false
    gh_cmd-->>publish: ["gh", "release", "create/edit", ...]
    publish->>User: DRY RUN: Would run: gh release create/edit ...

Loading

_{Last reviewed commit: 0aedeee}

[claude]

Review

Overall the changes are clean and well-motivated — the dry-run UX improvement and github_release_command extraction are both reasonable. A couple of minor issues noted inline.

Notes

Dry-run always previews create (not edit): By design, the dry-run skips the gh release view probe (probe_existing: false) and always shows the create command. The third puts message — "If the release already exists, the live run will use gh release edit instead" — correctly warns users about this. No action needed, just confirming the intent is clear.

probe_existing boolean parameter: Using a boolean to toggle whether a side-effect (network call) occurs is a mild code smell, but given this is internal release tooling with a small surface area it's acceptable. The alternative would be two separate functions (preview_release_command / live_release_command), which may be cleaner if this helper ever grows.

Docs: The new AUTO_CONFIRM=true example and the note under During the Release are clear and well-placed.

[claude]

The gem_root: keyword is required here even when probe_existing: false, where it's never used. The dry-run caller passes gem_root: gem_root purely to satisfy the signature.

An earlier iteration of this PR used gem_root: nil with an internal guard, which was more expressive — callers that don't need the probe don't need to pass gem_root at all. Consider restoring that pattern:

Suggested change

	def github_release_command(gem_root: nil, release_context:, notes_file_path:, probe_existing: true)
	def github_release_command(gem_root: nil, release_context:, notes_file_path:, probe_existing: true)

And add back the guard before the probe:

abort "❌ Internal error: github_release_command requires gem_root when probe_existing is true." unless gem_root

This makes the API more honest about which argument is actually required and when.

[claude]

The three-line dry-run block is functional, but the first and third lines express the same caveat in slightly different ways. The third line is the more precise one.

Consider collapsing to avoid the redundancy and potential confusion about what the command preview actually represents:

Suggested change

	)
	puts "DRY RUN: Would create or update GitHub release #{release_context[:tag]}#{release_context[:prerelease] ? ' (prerelease)' : ''}"
	puts "DRY RUN: Would run: #{Shellwords.join(preview_command)}"
	puts "DRY RUN: Would run (assuming new release): #{Shellwords.join(preview_command)}"
	puts "DRY RUN: If the release already exists, the live run will use `gh release edit` instead."

Dropping the first generic "Would create or update" line keeps the output focused on what's actionable — the actual command.

[claude]

Review

Clean, low-risk improvement to the release tooling UX. The refactoring into github_release_command is a solid consolidation, the dry-run messaging additions are genuinely useful, and the AUTO_CONFIRM documentation is a good addition for CI/scripted workflows.

Issues

Minor API inconsistency — see inline on github_release_command. The final commit changed gem_root: nil (optional, with a guard) back to gem_root: (required always), which means callers passing probe_existing: false still have to provide gem_root even though it's never read. The earlier gem_root: nil + guard approach was more expressive and worth restoring.

Dry-run output redundancy — see inline on the three-line dry-run block. The first and third lines both hedge about create-vs-edit; collapsing to two lines with a clearer label ("assuming new release") avoids the redundancy.

Looks good

• Refactoring logic out of publish_or_update_github_release into the helper is clean and the call sites are straightforward.
• The ensure_git_tag_exists! call correctly remains before the dry-run early return so preflight checks still run.
• Confirmation-prompt changes (if dry_run ... else confirm_or_abort!) are more idiomatic than the original unless dry_run guard and communicate intent better.
• Documentation additions are accurate and well-placed.

[claude]

The dry-run always shows the gh release create command (because probe_existing: false), but the follow-up note on this very line tells the user the live run might use gh release edit instead. This means the "Would run:" line can be actively misleading when the release already exists.

Two options to consider:

Option A – Probe existence during dry-run too (same as the live path), passing gem_root:

Suggested change

	puts "DRY RUN: If the release already exists, the live run will use `gh release edit` instead."
	preview_command = github_release_command(
	gem_root: gem_root,
	release_context: release_context,
	notes_file_path: "<release-notes-file>",
	probe_existing: true
	)

This shows the exact command that would run, at the cost of one extra gh release view call.

Option B – Keep probe_existing: false but be explicit that only the create form is shown:

Suggested change

	puts "DRY RUN: If the release already exists, the live run will use `gh release edit` instead."
	puts "DRY RUN: Would create or update GitHub release #{release_context[:tag]}#{release_context[:prerelease] ? ' (prerelease)' : ''}"
	puts "DRY RUN: Would run (create form; edit form used if release already exists): #{Shellwords.join(preview_command)}"

Less network traffic, still honest about the uncertainty.

[claude]

The gem_root: nil default combined with a runtime abort when probe_existing: true is a mixed API contract. A caller who forgets gem_root: gets a Ruby nil rather than an ArgumentError, and the error won't surface until after the gh release view probe is attempted (which would pass nil to chdir:).

Consider making gem_root required when probe_existing is true by documenting the intent more clearly, or splitting into two methods. That said, since this is internal release tooling and the abort message is clear, this is low severity.

[claude]

Review Summary

Overall this is a nice UX improvement to the release tooling — explicit dry-run messaging and the AUTO_CONFIRM documentation fill genuine gaps. The github_release_command refactor is clean.

Two inline comments posted:

1. Misleading dry-run command preview (primary concern): The dry-run always shows gh release create (via probe_existing: false), but the accompanying note acknowledges the live run might use gh release edit. The "Would run:" line can therefore be wrong in the common case where a prerelease was already created. Two fix options are in the inline comment — probing existence during dry-run, or rephrasing the output to make the uncertainty explicit.

2. gem_root: nil + runtime abort (low severity): The function signature accepts nil for gem_root but aborts at runtime if probe_existing: true. A nil gem_root would actually be passed to system's chdir: before the guard is even reached (the guard is on line 376, after the system call on line 378). Worth double-checking the ordering.

No security or performance concerns — the changes are isolated to release rake tasks and documentation.