Skip to content

ci: harden publish workflow against non-fast-forward bump push#25

Merged
sweetmantech merged 1 commit into
mainfrom
ci/harden-publish-workflow
Jun 25, 2026
Merged

ci: harden publish workflow against non-fast-forward bump push#25
sweetmantech merged 1 commit into
mainfrom
ci/harden-publish-workflow

Conversation

@sweetmantech

@sweetmantech sweetmantech commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

Why

The Publish to npm workflow failed twice on cli#24's release:

  1. First run: bad NPM_TOKENE404 at pnpm publish (token since fixed).
  2. Re-run: failed before publish, at the version-bump push —
    ! [rejected] main -> main (fetch first). The re-run checked out the
    original pre-bump SHA, and git push was non-fast-forward because the first
    run had already pushed the 0.1.14 bump to main.

Net: main is at 0.1.14 but npm is still 0.1.13 (never published).

Fix

  • checkout with ref: main + fetch-depth: 0 — the job always operates on the latest main tip (re-runs stop using a stale SHA) with full history for the rebase.
  • git pull --rebase origin main before the bump — race safety net so the push is always fast-forward.
  • git push origin HEAD:main (explicit) + capture the new version straight from npm version output (removes the node -p require()).
  • workflow_dispatch trigger so a publish can be re-kicked from the Actions UI without pushing a commit.

Effect on merge

Merging this is itself a push to main → triggers a fresh run from the current tip (0.1.14) → bumps to 0.1.15 → publishes with the (now valid) token. After it goes green, npm view @recoupable/cli version should show 0.1.15 with the emails command rename.

Gate reminder (chat#1815): don't promote api#711 to prod (api#715) until this publishes.

🤖 Generated with Claude Code


Summary by cubic

Hardened the npm publish workflow so the version-bump push is always fast-forward, even on re-runs or races. The job now operates from the latest main and supports manual runs.

  • Bug Fixes

    • Checkout with ref: main and fetch-depth: 0 to always use the latest main with full history.
    • Rebase before bumping: git pull --rebase origin main to keep the push fast-forward.
    • Push explicitly with git push origin HEAD:main.
    • Read the new version from npm version output (drops the node -p require()).
  • New Features

    • Add workflow_dispatch to trigger a publish from the Actions UI without a new commit.

Written for commit 050a335. Summary will update on new commits.

Review in cubic

The version-bump step commits + pushes to main from CI, which raced/failed on
re-runs: a re-run checked out the original (pre-bump) SHA and its `git push` was
rejected as non-fast-forward once main had moved ahead.

- checkout `ref: main` + `fetch-depth: 0` so the job always works from the
  latest main tip (re-runs no longer use a stale SHA) with full history.
- `git pull --rebase origin main` before bumping — race safety net.
- `git push origin HEAD:main` (explicit) and capture the version straight from
  `npm version` output (drops the node -p require()).
- add a `workflow_dispatch` trigger so a publish can be re-kicked from the
  Actions UI without pushing a commit.

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

coderabbitai Bot commented Jun 25, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@sweetmantech, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 30 minutes and 38 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

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

🚦 How do rate 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 see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 4e9a68b9-d8e4-4e03-8ac8-fa85cbce4835

📥 Commits

Reviewing files that changed from the base of the PR and between 0b3947d and 050a335.

📒 Files selected for processing (1)
  • .github/workflows/publish.yml
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch ci/harden-publish-workflow

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

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

@sweetmantech sweetmantech merged commit 5e54b96 into main Jun 25, 2026
3 checks passed
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.

1 participant