fix(cli): make bundle upload channel linking CI-visible

[riderx]

Summary (AI generated)

• Stop implying final success at zip upload time (Bundle zip uploaded… instead of Bundle uploaded 💪).
• On successful stable channel assignment, always print explicit success lines:
  • Linked @<bundle> to channel <name> as stable.
  • Cleared progressive rollout on <name>. when an active rollout was reset (in addition to the existing warn)
  • Link device to this bundle to try it: … for non-public channels (no longer skipped when rollout was cleared)
• Add opt-in --fail-on-active-rollout for CI pipelines that must not reset an active rollout without --rollout / --rollout-advance.
• Update CLI README, bundle webdocs, and release-management skill docs.

Motivation (AI generated)

Users reported bundle upload --channel … exiting 0 after “Bundle uploaded” even when they believed the bundle was not linked. The zip upload message printed before channel assignment finished, and when a channel had an active progressive rollout the CLI printed only the rollout-reset warn while skipping the “Link device…” / public-channel info — so CI heuristics falsely concluded the bundle was not linked after a successful link+rollout-reset.

Business Impact (AI generated)

• Reduces false confidence in CI/CD logs when channel linking is the real success criterion.
• Fixes false “not linked” conclusions when stable upload clears an active rollout.
• Gives teams an explicit guard (--fail-on-active-rollout) to catch accidental rollout resets in automation.
• Preserves default Capgo-style --channel uploads (link stable + clear leftover rollout, exit 0).

Test Plan (AI generated)

• bun run test:fail-on-active-rollout (helpers + checkValidOptions guard)
• bun run test:fail-on-incompatible (unchanged)
• bun run build + bun run lint in cli/
• bun test:unit tests/upload-channel-link.unit.test.ts
• CI green on PR

Generated with AI

  

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

@coderabbitai review

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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.}

[codspeed]

Merging this PR will not alter performance

✅ 43 untouched benchmarks
⏩ 2 skipped benchmarks¹

---

_{Comparing cursor/cli-upload-rollout-ci-28aa (e26e32a) with main (62dd028)}

Footnotes

1. 2 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[Nei1eveN]

AI-assisted review: Codex reviewed the public change and ran a local reproduction with mocked I/O on behalf of Neil Potot. One new correctness finding is attached. No customer data or production systems were used.

[Nei1eveN]

[P2] Enforce the rollout guard when the stable promotion is committed

AI disclosure: Codex performed this review and local mocked-I/O reproduction for Neil Potot.

At e26e32a3bd1a18c1ce6f88ee4d8d05dda20f3c75, --fail-on-active-rollout is checked only before upload. uploadTargetChannels retains that snapshot and the assignment loop reuses it after upload. Neither setVersionInChannel nor promoteExistingChannel checks the flag again, and the PUT body does not convey it to the server.

Reproduction with a normal, authorized concurrent rollout:

1. Start a stable upload with --channel production --fail-on-active-rollout while the channel has no active rollout.
2. Let preflight finish, then start a rollout from another deployment or the dashboard while the bundle is uploading.
3. Resume the first upload. It uses the earlier inactive snapshot, sends PUT /bundle and reports stable-link success, despite the now-active rollout.

I ran the exact current preflight, assignment, promotion and setChannelInTransaction functions locally with mocked I/O. The control case (rollout active before preflight) rejected without a write. Changing state after preflight instead reached the server helper's unconditional channel-version UPDATE, returned true, and printed success with no rollout warning. This bypasses the new flag precisely while it is intended to prevent a stable promotion from replacing an active rollout.

Please carry the opt-in guard to the stable-promotion endpoint and check the current rollout fields while holding its existing channel row lock, before the UPDATE; preserve existing behavior when the flag is absent. Cover the same guarantee for the self-assign path. A fresh CLI read alone would still leave a smaller race.

Validation: Node 22, source-extracted functions, synthetic channel and mocked permissions/API/DB. No production requests or live database test; database trigger effects were not executed.

[github-actions]

@coderabbitai review

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud