Patch upstream tags oldest-first in auto-patch workflow - #1
Merged
Conversation
When a backlog accumulates between scheduled runs, the previous newest-first order caused each subsequent run to patch an older tag, which the deployment repo would then adopt as default via Bitrise CI. Iterating ascending ensures the last patched branch is the newest tag. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ramil-bitrise
approved these changes
Jun 9, 2026
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
2 participants
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.
Summary
.github/workflows/auto-patch-upstream.ymlfrom newest-first (sort -rV) to oldest-first (sort -V).MAX_PATCHES=1is unchanged — still one tag per workflow run.Why
When multiple upstream releases land between scheduled runs, the previous order patched the newest tag first and then walked backwards on each subsequent run. Each patched branch triggers Bitrise CI to update the deployment repo's default to that branch's version, so the default ended up regressing to the oldest tag of the batch.
Iterating ascending means the last branch pushed during a catch-up sequence is always the newest tag, so the deployment default lands on the newest.
Test plan
workflow_dispatch) and confirm the next unpatched tag chosen is the oldest one missing.releases/v<oldest-missing>-bitriseis created and pushed.🤖 Generated with Claude Code