chore: bump develop snapshot target to 4.0.1 - #2608
Conversation
Manual replacement for the `bump-develop-version.yml` PR that didn't fire on the v4.0.0 GA. The workflow triggers on `release: published` events, but neither the original release.yml-created release nor the subsequent pre-release toggle (web UI and `gh release edit` both tried) dispatched an event Actions could pick up — `softprops/action-gh-release` used the default `GITHUB_TOKEN`, which can't trigger downstream workflows (documented Actions limitation), and the post-publish toggle didn't fire a fresh `release: published` either. Sets `wheels.json` to `4.0.1` so subsequent develop snapshots resume tagging correctly as `4.0.1-snapshot.<run>`. The maintainer makes the actual scope decision at the next GA's tag-cut time — this is just the snapshot baseline. If the next GA ends up being a minor or major bump, snapshot version strings still sort strictly lower than any of those. Follow-up: add `workflow_dispatch` to `bump-develop-version.yml` or switch its trigger to something `GITHUB_TOKEN` can fire (e.g., `repository_dispatch`). Signed-off-by: Peter Amiri <peter@alurium.com>
![wheels-bot[bot]](https://avatars.githubusercontent.com/in/3657588?s=60&v=4){kind=small}
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: This PR makes a single-field version bump in wheels.json from 4.0.0 to 4.0.1 — a manual replacement for the automated bump-develop-version.yml PR that failed to fire due to the well-documented GITHUB_TOKEN limitation on downstream workflow dispatch. The change is correct, the PR description is thorough and honest about root cause and follow-up, the commit follows conventional-commit rules, and the DCO sign-off is present. No tests, docs, or CHANGELOG updates are warranted for a snapshot baseline bump. Verdict: approve.
Correctness
The diff is exactly what the PR claims: one field in wheels.json changes from "4.0.0" to "4.0.1". The PR description correctly explains why the automated workflow didn't fire (softprops/action-gh-release uses the default GITHUB_TOKEN, which cannot trigger downstream release: published events). The proposed follow-up — add workflow_dispatch to bump-develop-version.yml or switch to repository_dispatch — is the right fix and is tracked as a separate item.
Version semantics are sound: 4.0.1-snapshot.<run> strings sort strictly lower than a 4.0.1 GA tag, so the tap auto-bump and brew upgrade flow continues to work correctly regardless of whether the next GA turns out to be a patch, minor, or major bump.
Commits
Single commit 32eafaf80:
- Type
chore— valid percommitlint.config.js. - Subject "bump develop snapshot target to 4.0.1" — sentence-case, 42 chars, well within the 100-char limit.
- DCO
Signed-off-by: Peter Amiri <peter@alurium.com>— present and matches the PR author. - Body explains the why (workflow limitation, manual steps attempted, and follow-up plan). No issues.
Wheels Bot — Reviewer B (round 1)A's review checks out. The diff is a single-field version bump in SycophancyNone detected. A's approval cites specific evidence for each point rather than generic praise. False positivesNone detected. All of A's claims verified against the actual commit and diff:
Missed issuesNone detected. Verdict alignmentA's ConvergenceAligned. The joint recommendation is approve — no changes needed. This SHA is review-clean. |
…2615) * ci(release): fire bump-develop via repository_dispatch (fix #2609) The release:published event emitted by release.yml's "Create GitHub Release" step uses the default GITHUB_TOKEN, which (by GitHub's design) cannot trigger downstream workflows. As a result, bump-develop-version.yml never fired on the v4.0.0 GA cut and the maintainer had to open the develop-bump PR manually (#2608). Fix: - release.yml's existing "Dispatch downstream package managers" step now also dispatches a `bump-develop` event at wheels-dev/wheels itself (only when CHANNEL=stable), piggybacking on the same PAT (DOWNSTREAM_DISPATCH_TOKEN) that already drives the homebrew/chocolatey dispatches. - bump-develop-version.yml listens for `repository_dispatch: types: [bump-develop]` and adds a `workflow_dispatch` manual fallback. The prerelease/target-branch eligibility gates can be deleted because the dispatcher itself only fires for stable (which by construction comes from main and is non-prerelease). - RELEASE_PLAYBOOK.md updated to document the dispatch chain plus a manual-fallback entry in the failure-modes table. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci(release): fail loud on unparseable workflow_dispatch input Reviewer A in #2615 found a real correctness issue: the SemVer-mismatch guard exited 0, which marks the step succeeded and lets GitHub Actions run the unguarded "Update wheels.json" and "Open bump PR" steps with NEW_VERSION/RELEASED_VERSION unset. Concrete failure: jq writes '"version": ""' to wheels.json and peter-evans/create-pull-request opens 'auto-bump/develop-' with title 'chore: bump develop snapshot target to '. The primary repository_dispatch path is safe — release.yml's CHANNEL=stable branch only fires after -snapshot/-rc filtering, so the payload is guaranteed bare SemVer. This only affects the workflow_dispatch fallback when an operator types something like '4.0.1-rc1'. Fix: exit 1 with ::error:: so the run goes red and the operator re-fires with corrected input. Applied Reviewer A's Option A (Reviewer B converged). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 participant
Automated bump triggered by GA release
4.0.0— but the trigger fired manually becausebump-develop-version.ymldidn't pick up the release event.Sets
wheels.jsonversion to4.0.1so subsequent develop snapshots are tagged4.0.1-snapshot.<run>.This is a baseline, not a commitment. If the next GA release ends up being a minor or major bump, the snapshot version strings still sort strictly lower than any of those, so the tap auto-bump and
brew upgradecontinue to work correctly. The maintainer makes the actual scope decision at the next GA's tag-cut time, not here.Why this is manual
bump-develop-version.ymllistens forrelease: types: [published]. The v4.0.0 release was published byrelease.ymlusing the defaultGITHUB_TOKEN, which can't trigger downstream workflows (documented Actions limitation). A follow-up toggle (web UI andgh release editboth attempted) also failed to fire a freshrelease: publishedevent — possibly because GitHub doesn't re-firepublishedfor arelease → pre-release → releaseround-trip on the same release object.Follow-up tracked separately: add
workflow_dispatchtobump-develop-version.yml(so the maintainer can manually fire it next time) or switch its trigger torepository_dispatch(whichrelease.ymlalready fires for the homebrew/scoop bumps and could fire for develop-bump too).Verification
$ jq -r '.version' wheels.json 4.0.1Single-line diff (kept original 4-space indentation rather than letting
jqreformat the file — that's the only deviation from what the workflow would have produced).