Repository navigation
ci: release setup-cli when its default mergify-cli version changes - #25
Merged
Conversation
Renovate bumps the default mergify-cli version in action.yml and the dependencies queue merges it, but nobody tagged a release afterwards: main moved to 2026.10.8 on 2026-10-27 while the newest release, v1.3.0, still installs 2026.7.21.1, and gha-mergify-ci, which pins a setup-cli release, kept the old CLI. Every push to main now compares the default version in action.yml with the one in the latest vX.Y.Z release. When they differ, it releases the next minor (v1.4.0 after v1.3.0, the bump v1.2.0 and v1.3.0 used for their CLI updates) at the pushed commit. The notes open with the CLI version and continue with GitHub's generated ones. Comparing with the release rather than with the push's own diff lets the next push catch up a run that failed. It refuses, and fails the run, when a commit since the latest release is marked breaking (`type!:` or `BREAKING CHANGE:`), since that needs a new major cut by hand, and when the tag already exists without a published release, since the API would publish on that tag's commit. A release created with GITHUB_TOKEN triggers no workflow, so the major tag move now runs in the same job, on every run: push, release and dispatch. It already picks the newest release of the major, and now skips when the tag is already there, so a move that failed or was skipped is repaired by the next push. Merging this is itself a push to main: it releases v1.4.0 with mergify-cli 2026.10.8 at its merge commit, unless v1.4.0 was cut by hand first, and moves v1 from v1.3.0 to it. workflow_dispatch without a tag moves the newest release's major tag and dry-runs the release check on the dispatched ref: it prints the full notes a push there would publish, and creates nothing. Fixes MRGFY-11553 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Change-Id: I13deb11322db2b37c9fe7fe945b780967377005a
Contributor
Merge Protections🟢 All 6 merge protections satisfied — ready to merge. Show 6 satisfied protections🟢 🤖 Continuous Integration
🟢 👀 Review Requirements
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 🔎 Reviews
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
sileht
marked this pull request as ready for review
November 3, 2026 22:15
jd
approved these changes
Nov 3, 2026
kozlek
approved these changes
Nov 3, 2026
Contributor
✅ Merged into
|
1 similar comment
Contributor
✅ Merged into
|
mergify
Bot
deleted the
devs/sileht/mrgfy-11553-setup-cli-auto-release/release-setup-cli-default-mergify-cli-version--13deb113
branch
November 3, 2026 22:42
mergify Bot
pushed a commit
that referenced
this pull request
Nov 5, 2026
The push run of #25 released v1.4.0 and then left v1 on v1.3.0: the major-tag step listed the releases right after creating v1.4.0, the list did not show it yet, and the step logged "v1 already points at v1.3.0". Every `Mergifyio/setup-cli@v1` user stayed on the old default mergify-cli. This is not a rare race. On a throwaway repository, the releases list missed a release created just before in 24 of 25 tries, and took 0.6 to 1.8 s to show it, while refs/tags/<tag> resolved to the right commit 25 times out of 25. The step now counts the release its run cut, or the published release that triggered it, on its own before picking the newest, whatever the list returns. A patch on an older minor still never moves the tag backwards, and a dispatched tag still only picks the major. The commit is resolved from refs/tags/<tag>, so a branch with the same name cannot be picked. Merging this is a push to main, so its run points v1 at v1.4.0 if v1 is still on v1.3.0 by then. Fixes MRGFY-11553 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Approved-by: jd <2644+jd@users.noreply.github.com>
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Renovate bumps the default mergify-cli version in action.yml and the
dependencies queue merges it, but nobody tagged a release afterwards:
main moved to 2026.10.8 on 2026-10-27 while the newest release, v1.3.0,
still installs 2026.7.21.1, and gha-mergify-ci, which pins a setup-cli
release, kept the old CLI.
Every push to main now compares the default version in action.yml with
the one in the latest vX.Y.Z release. When they differ, it releases the
next minor (v1.4.0 after v1.3.0, the bump v1.2.0 and v1.3.0 used for
their CLI updates) at the pushed commit. The notes open with the CLI
version and continue with GitHub's generated ones. Comparing with the
release rather than with the push's own diff lets the next push catch up
a run that failed.
It refuses, and fails the run, when a commit since the latest release is
marked breaking (
type!:orBREAKING CHANGE:), since that needs a newmajor cut by hand, and when the tag already exists without a published
release, since the API would publish on that tag's commit.
A release created with GITHUB_TOKEN triggers no workflow, so the major
tag move now runs in the same job, on every run: push, release and
dispatch. It already picks the newest release of the major, and now
skips when the tag is already there, so a move that failed or was
skipped is repaired by the next push.
Merging this is itself a push to main: it releases v1.4.0 with
mergify-cli 2026.10.8 at its merge commit, unless v1.4.0 was cut by hand
first, and moves v1 from v1.3.0 to it.
workflow_dispatch without a tag moves the newest release's major tag and
dry-runs the release check on the dispatched ref: it prints the full
notes a push there would publish, and creates nothing.
Fixes MRGFY-11553
Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com