feat(deploy): create release-line branch on prod release for hotfixes (CPL-358) - #583
Closed
GTC6244 wants to merge 2 commits into
Closed
Conversation
… (CPL-358) The tag-triggered prod release (deploy-prod-1-propose.yml) now lands each released commit on a minor-version branch release/vX.Y via a new create-release-branch job. All patch releases on a line share one branch, giving hotfixes to a shipped version a stable home that never moves as main advances. The job only fast-forwards an existing branch (never force-pushes), so hotfix commits already on the line are never discarded. Documented the hotfix workflow in architectureDocs/deployment/vm-code-upgrade.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR extends the tag-triggered production release workflow to maintain a stable minor-version “release-line” branch (release/vX.Y) for each shipped line, enabling safer hotfix releases without relying on main. It also documents the intended hotfix flow.
Changes:
- Add a
create-release-branchjob todeploy-prod-1-propose.ymlthat creates or fast-forwardsrelease/vMAJOR.MINORon tag pushes. - Document the release-line/hotfix workflow in
architectureDocs/deployment/vm-code-upgrade.md.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| architectureDocs/deployment/vm-code-upgrade.md | Documents how release-line branches are used for hotfixes and how tag pushes advance the line. |
| .github/workflows/deploy-prod-1-propose.yml | Adds a tag-only job that creates/advances release/vX.Y branches to keep hotfix work on a stable line. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…safe Address PR review: git fetch always writes FETCH_HEAD, but the origin/$BRANCH remote-tracking ref may not exist under actions/checkout's narrow fetch refspec, so base the fast-forward ancestor check on FETCH_HEAD. Update the hotfix docs to fetch before switching so the commands work on a fresh clone. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
Author
|
Holding for any other prod related changes. |
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 tag-triggered production release workflow (
deploy-prod-1-propose.yml) now lands each released commit on a minor-version branchrelease/vX.Yvia a newcreate-release-branchjob, so all patch releases on a line share one branch and hotfixes to a shipped version get a stable home that never moves asmainadvances. The job runs only on tag pushes and only fast-forwards an existing branch (never force-pushes), so hotfix commits already on a line are never discarded. The hotfix workflow is documented inarchitectureDocs/deployment/vm-code-upgrade.md.🤖 Generated with Claude Code