ci(release): cut 1.x maintenance releases from support/1.x with major/minor docker tags#1980
Merged
Merged
Conversation
Parameterize the release workflow with a `base` input so releases can be cut from either develop (mainline) or support/1.x (1.x maintenance): - prepare: check out and release from `base`; support releases push the release branch only (no `-s ours` no-merge into develop). - deploy: publish moving `major` and `major.minor` docker tags alongside the exact `major.minor.patch`; `latest` moves only for the highest stable release, and pre-releases publish only their exact version tag. - finalize: mainline keeps the git-flow finish (merge to main, tag, back-merge develop); support merges into the support branch and tags only, never touching main or develop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C5bGVS9PYHAbXzqiHZDXie
…ersion - Remove the manual `base` input; the release base is the branch the run is dispatched on (github.ref_name), so the ref and base can no longer diverge. - Add a fail-fast validation: a support/N.x run only accepts N.* versions, and a develop run is rejected when a support/<major>.x branch already exists (so a 1.x release can't be cut from develop by mistake). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C5bGVS9PYHAbXzqiHZDXie
The build workflow only triggered for develop (and feature/** in zilla), so pull requests targeting support/1.x were never built. Add support/** to the push and pull_request branch filters so support branches build like develop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C5bGVS9PYHAbXzqiHZDXie
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C5bGVS9PYHAbXzqiHZDXie
Consolidate the per-line CHANGELOG steps into a single step that explicitly checks out the base branch (github.ref_name) before generating, committing and pushing CHANGELOG.md. Both develop and support/1.x end up with a complete, regenerated CHANGELOG for their line instead of relying on git-flow leaving HEAD on develop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C5bGVS9PYHAbXzqiHZDXie
Restore the release branch's base into local git config (gitflow.branch.release/<version>.base) before a single `git flow release finish`. git-flow stores that base only in local .git/config and never pushes it, so it is absent in the finalize job's fresh checkout; restoring it lets one finish command do the right thing per line: a develop release merges into main and back-merges develop, while a support/N.x release merges into that support branch and tags only, never touching main or develop. Replaces the hand-rolled support finish. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C5bGVS9PYHAbXzqiHZDXie
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.
Description
Enables git-flow
support/1.xreleases so 1.x minor/patch versions can be cut fromsupport/1.xwhiledevelopmoves on to v2.github.ref_name) — no manualbaseinput, so the ref and base can't diverge.support/N.xonly acceptsN.*, and adeveloprun is blocked when asupport/<major>.xbranch already exists (so a 1.x release can't be cut from develop by mistake).major(1) andmajor.minor(1.5) tags alongside the exactmajor.minor.patch. The floatinglatest/alpinepointers move only for the highest stable release across all tags, sosupport/1.xkeepslatestuntil a stable 2.x ships from develop; pre-releases publish only their exact version tag.support/*release merges into the support branch and tags only — it never advancesmainor back-merges intodevelop. Mainline (develop) releases keep the existing git-flow finish.Targets
support/1.x. Companion PR againstdevelop(claude/release-workflow-support-branches-ss82ns) brings the same workflow to the mainline so v2 releases also emit the new2/2.0tags.Follow-up (deferred): switch
examples/*/compose.yamldefaults onsupport/1.xfrom${ZILLA_VERSION:-latest}to${ZILLA_VERSION:-1}.No associated issue.
🤖 Generated with Claude Code
Generated by Claude Code