Skip to content

fix(release): call min completions print in the release job - #1034

Merged
norrietaylor merged 1 commit into
mainfrom
fix/release-completions-print
Jul 29, 2026
Merged

fix(release): call min completions print in the release job#1034
norrietaylor merged 1 commit into
mainfrom
fix/release-completions-print

Conversation

@norrietaylor

@norrietaylor norrietaylor commented Jul 29, 2026

Copy link
Copy Markdown
Member

What broke

Release run 30425725370 failed in the release job's Generate completions step:

error: unrecognized subcommand 'bash'
Usage: minimal-linux-amd64 completions [OPTIONS] <COMMAND>
##[error]Process completed with exit code 2.

#1009 split min completions <shell> into min completions print <shell> and min completions install. The release job still called the flat form, so the step exited 2 and everything after it — GCS archive upload, Create Release, stage-installer — never ran. Every build job succeeded; only the packaging step is broken.

mip and minimald keep the flat completions <shell> verb, so their six lines are untouched.

The fix

  • The three min lines become completions print <shell>.
  • Their outputs are renamed min / _min / min.fish. The shim min completions print emits registers the command min (complete … _clap_complete_min min, compdef _clap_dynamic_completer_min min, complete --command min), and every shell autoloads a completion file by the command name — so the minimal / _minimal / minimal.fish files shipped in completions.tar.gz have been dead on arrival since the binary rename in #737. Flagging this as the one change beyond the literal build break; nothing in the tree consumes those filenames (the curl|sh installer generates its own via min completions install).

Verification

Locally, against cargo build -p minimal:

  • min completions print {bash,zsh,fish} — all three emit a shim, exit 0.
  • min completions bash — reproduces the run's exact error.
  • Registration target inspected in all three outputs: min, confirming the filename change.
  • release.yml re-parsed as YAML.

The step itself only runs on a release dispatch, so the real proof is the next release run — a dry_run: true dispatch exercises this step (it precedes the dry-run branch) without publishing anything.

Note

The release job's CLI invocations have no pre-merge coverage; a breaking CLI change lands and only a release run finds out. Worth a follow-up guard, out of scope here.

🤖 Generated with Claude Code

Note

Fix completions print call and output filenames for min binary in release job

The release job's "Generate completions" step was calling completions <shell> instead of completions print <shell> for the minimal binary, and writing files named minimal, _minimal, and minimal.fish instead of min, _min, and min.fish. This fixes both issues in release.yml.

Macroscope summarized b6384c7.

#1009 split `min completions <shell>` into `completions print` and
`completions install`; the release job still called the flat form, so
`Generate completions` exited 2 on run 30425725370 and the release never
reached GCS or the GitHub Release.

Switch the three `min` lines to `completions print <shell>`, and name
their outputs after the `min` binary (`min`, `_min`, `min.fish`) rather
than the crate: the shim `min` prints registers the command `min`, so a
shell only ever autoloads it from a file of that name — the
`minimal`/`_minimal` files shipped in `completions.tar.gz` since the
binary rename (#737) were dead on arrival. `mip` and `minimald` keep the
flat verb; only the `min` CLI changed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jul 29, 2026

Copy link
Copy Markdown

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 2 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 62fa9748-fdcf-4a6e-a116-c4098137674c

📥 Commits

Reviewing files that changed from the base of the PR and between df22d71 and b6384c7.

📒 Files selected for processing (1)
  • .github/workflows/release.yml

Comment @coderabbitai help to get the list of available commands.

@norrietaylor
norrietaylor merged commit dcdeec6 into main Jul 29, 2026
39 of 40 checks passed
@norrietaylor
norrietaylor deleted the fix/release-completions-print branch July 29, 2026 14:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants