Repository navigation
Conversation
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> Change-Id: Icf242be7761ae1385adc264082c2ce19cb4f2d16
Contributor
Merge Protections🔴 2 of 6 protections blocking · waiting on 👀 reviews
🔴 👀 Review RequirementsWaiting for
This rule is failing.
🔴 🔎 ReviewsWaiting for
This rule is failing.
Show 4 satisfied protections🟢 🤖 Continuous Integration
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
This branch had an error being 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.
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@v1user 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/ 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/, 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