Repository navigation
ci(npm): rebase-and-retry the version-bump push so publishes stop failing - #5762
Conversation
…ling master regularly moves while publish-npm.yml runs (nightly release and auto-changelog commits), so the bare 'git push' of the version bump was rejected with non-fast-forward and the job died before reaching 'npm publish'. Every run since 2026-06-29 failed this way, leaving @wailsio/runtime stale on npm at 3.0.0-alpha.95 while master's runtime source moved on - and every fresh 'wails3 init' pulls that stale package. Rebase onto current master and retry (5 attempts, backoff) before giving up. A genuine rebase conflict still fails the job loudly, and the publish step still only runs after the bump commit is safely on master.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe publish-npm GitHub Actions workflow now retries rejected ChangesWorkflow Push Retry
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/publish-npm.yml (1)
145-163: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winRebase conflicts aren't detected — they masquerade as repeated push failures.
The
runblock has noset -e, and the exit status ofgit pull --rebase origin master(Line 159) is never checked. If a real rebase conflict occurs, git leaves the repo mid-rebase with unmerged paths, but the script doesn't stop — it sleeps and loops back togit push, which fails again, then re-runsgit pull --rebasewhile already mid-rebase (which itself errors), silently, for all remaining attempts. The job eventually fails, but only after burning through all 5 attempts/backoff delays, and reports the generic "could not push after 5 attempts" message instead of surfacing the actual conflict — the opposite of "fails loudly" the PR intends.🔧 Proposed fix: detect rebase conflicts explicitly and fail fast
+ set -eo pipefail git add -A echo "Files committed back to master:" git status --short git commit -m "[skip ci] Publish `@wailsio/runtime` ${{ steps.bump-version.outputs.version }}" for attempt in 1 2 3 4 5; do if git push; then exit 0 fi echo "push rejected (attempt ${attempt}); rebasing onto current master" - git pull --rebase origin master + if ! git pull --rebase origin master; then + echo "::error::rebase onto origin/master failed — real conflict, aborting" + git rebase --abort || true + exit 1 + fi sleep $(( attempt * 5 )) done echo "::error::could not push the version bump after 5 attempts" exit 1🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/publish-npm.yml around lines 145 - 163, The retry loop in the publish step treats rebase conflicts like ordinary push retries, so it can keep looping while the repo is mid-rebase. Update the `run` block to fail fast on `git pull --rebase origin master` errors in this `git push` retry flow, and detect an in-progress rebase/unmerged paths before retrying. Use the existing commit/push loop logic and the `git pull --rebase origin master` step to surface the real conflict immediately instead of falling through to the generic 5-attempt failure.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.github/workflows/publish-npm.yml:
- Around line 145-163: The retry loop in the publish step treats rebase
conflicts like ordinary push retries, so it can keep looping while the repo is
mid-rebase. Update the `run` block to fail fast on `git pull --rebase origin
master` errors in this `git push` retry flow, and detect an in-progress
rebase/unmerged paths before retrying. Use the existing commit/push loop logic
and the `git pull --rebase origin master` step to surface the real conflict
immediately instead of falling through to the generic 5-attempt failure.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 96b14187-8331-48c0-848b-8cda8f530f80
📒 Files selected for processing (1)
.github/workflows/publish-npm.yml
2 participants
Description
Every
publish-npm.ymlrun since 2026-06-29 has failed at the Commit regenerated runtime + version bump step: master moves while the job runs (nightly release, auto-changelog commits), the baregit pushis rejected with non-fast-forward, and the job dies beforenpm publish. Net effect:@wailsio/runtimeon npm has been stale at3.0.0-alpha.95while master's runtime source moved on — and every stockwails3 initpullslatestfrom npm.This adds a rebase-and-retry loop (5 attempts, linear backoff) around the push. A genuine rebase conflict still fails the job loudly, and the publish step still only runs after the bump commit is safely on master, so the version-bump-before-publish invariant is preserved.
After merging, a manual
gh workflow run publish-npm.ymlwill refresh npm (and pick up #5690's runtime change once that lands).Type of change
Checklist
Summary by CodeRabbit