Master-orchestrated release with LTS patch support#1680
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe release process now uses manual workflow dispatches with explicit tag and branch inputs. Release tagging, GitHub release creation, latest-tag detection, downstream deployment dispatches, and release documentation are updated to match the new workflow-driven flow. ChangesRelease automation changes
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Operator
participant BumpVersionWorkflow
participant Git
participant BuildReleaseWorkflow
participant NetlifyDeployWorkflow
Operator->>BumpVersionWorkflow: dispatch bump_type and base_branch
BumpVersionWorkflow->>BumpVersionWorkflow: validate bump_type against base_branch
BumpVersionWorkflow->>Git: checkout base_branch, commit, tag, push
BumpVersionWorkflow->>BuildReleaseWorkflow: dispatch with tag and make_latest
BumpVersionWorkflow->>NetlifyDeployWorkflow: dispatch when tag is latest
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
86da13c to
11e1a02
Compare
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (2)
scripts/is_latest_tag.sh (1)
1-1: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winAdd
pipefailto avoid silently swallowinggit tagfailures.With only
set -e, a failure ingit tag(first command of the pipe on Line 15) is masked bytail -1's exit status, sohighestsilently becomes empty and the script always printsfalse. Downstream consumers (make_latest, Netlify deploy gate) would then treat an actually-latest tag as non-latest without any error signal.🛡️ Proposed fix
#!/bin/bash # (C) 2026 GoodData Corporation # Prints "true" if the given tag is the highest semver among all v*.*.* tags, # otherwise "false". Requires the repository's tags to be present locally # (callers should checkout with fetch-depth: 0). # Usage: is_latest_tag.sh vX.Y.Z -set -e +set -eo pipefailAlso applies to: 7-7, 15-15
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@scripts/is_latest_tag.sh` at line 1, Add pipefail to the shell setup in is_latest_tag so failures from the git tag pipeline are not masked by tail; update the script’s initial shell options near the shebang and keep the existing highest/latest-tag logic unchanged. Use the script entrypoint and the pipeline that computes highest to locate the fix..github/workflows/bump-version.yaml (1)
78-92: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueDuplicated commit logic across branches.
git add -A/git commit -m "Release ${NEW_VERSION}"is repeated in both themasterandrel/*branches of the conditional. Hoisting it above theifwould remove the duplication.♻️ Proposed simplification
+ git add -A + git commit -m "Release ${NEW_VERSION}" if [ "$REF" = "master" ]; then RELEASE_BRANCH="rel/${NEW_VERSION}" - git checkout -b "$RELEASE_BRANCH" - git add -A - git commit -m "Release ${NEW_VERSION}" + git branch "$RELEASE_BRANCH" git push origin "$RELEASE_BRANCH" git checkout master git merge "$RELEASE_BRANCH" git push origin master else # rel/* patch release: commit onto the maintenance branch, no master merge - git add -A - git commit -m "Release ${NEW_VERSION}" git push origin "HEAD:${REF}" fi🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/bump-version.yaml around lines 78 - 92, The release step in the workflow duplicates the same git staging and commit logic in both branches of the conditional. Refactor the shell block around the release branch handling so `git add -A` and `git commit -m "Release ${NEW_VERSION}"` run once before the `if`, then keep only the branch-specific push/merge behavior in the `master` and `rel/*` paths. Use the existing `REF`, `NEW_VERSION`, and `RELEASE_BRANCH` variables to preserve the current release flow.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build-release.yaml:
- Around line 66-69: The Checkout step in the build-release workflow is
persisting credentials unnecessarily. Update the actions/checkout@v5
configuration in the Checkout job to set persist-credentials to false, since
this job only needs repository history for is_latest and does not require the
GITHUB_TOKEN to remain in git config.
- Around line 70-72: The `Determine if this tag is the latest release` step is
vulnerable because `github.ref_name` is interpolated directly into the shell
command in `run:`. Update the workflow to pass the tag name through an `env:`
variable and reference that variable inside the script, so
`scripts/is_latest_tag.sh` receives the tag safely without shell expansion.
In @.github/workflows/bump-version.yaml:
- Around line 32-50: The shell validation in the workflow is interpolating
GitHub context values directly into the run script, which creates a
template-injection risk. Update the bump-version job so `github.ref_name`,
`github.event.inputs.bump_type`, and any later use such as
`steps.bump.outputs.new_version` are passed via `env:` and then referenced as
shell variables inside the script. Apply the same pattern in the `Validate
branch and bump type` step and the later version-bump/release steps to keep the
logic in the existing workflow steps but remove direct `${{ }}` expansion from
shell text.
In @.github/workflows/netlify-deploy.yaml:
- Around line 9-17: The check-latest job currently relies on inherited token
permissions and checkout may persist credentials unnecessarily. Update the
check-latest job in the netlify-deploy workflow to explicitly use
least-privilege permissions for its read-only git history access, and set
persist-credentials to false on the actions/checkout@v5 step. Keep the change
scoped to the check-latest job and its Checkout step.
- Around line 18-25: The latest-release check in the Netlify workflow is
interpolating github.ref_name directly inside the shell script, which creates a
template-injection risk. Update the “Determine if this deploy is for the latest
release” step in the workflow to pass the tag name through env and reference
that variable in the run block instead of using direct interpolation, keeping
the logic in the latest step and the is_latest_tag.sh call unchanged otherwise.
---
Nitpick comments:
In @.github/workflows/bump-version.yaml:
- Around line 78-92: The release step in the workflow duplicates the same git
staging and commit logic in both branches of the conditional. Refactor the shell
block around the release branch handling so `git add -A` and `git commit -m
"Release ${NEW_VERSION}"` run once before the `if`, then keep only the
branch-specific push/merge behavior in the `master` and `rel/*` paths. Use the
existing `REF`, `NEW_VERSION`, and `RELEASE_BRANCH` variables to preserve the
current release flow.
In `@scripts/is_latest_tag.sh`:
- Line 1: Add pipefail to the shell setup in is_latest_tag so failures from the
git tag pipeline are not masked by tail; update the script’s initial shell
options near the shebang and keep the existing highest/latest-tag logic
unchanged. Use the script entrypoint and the pipeline that computes highest to
locate the fix.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 3ff6ad7b-c2d7-4d02-964c-ae5b02ea6a77
📒 Files selected for processing (9)
.github/workflows/build-release.yaml.github/workflows/bump-version.yaml.github/workflows/netlify-deploy.yamlMAINTENANCE.mddocs/superpowers/plans/2026-07-01-consolidated-release.mddocs/superpowers/plans/2026-07-01-lts-patching-old-versions.mddocs/superpowers/specs/2026-07-01-consolidated-release-design.mddocs/superpowers/specs/2026-07-01-lts-patching-old-versions-design.mdscripts/is_latest_tag.sh
| check-latest: | ||
| runs-on: ubuntu-latest | ||
| outputs: | ||
| is_latest: ${{ steps.latest.outputs.is_latest }} | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v5 | ||
| with: | ||
| fetch-depth: 0 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Harden check-latest job: least-privilege permissions and no credential persistence.
No permissions: block means this job inherits the default (potentially broad) token permissions even though it only reads git history. Also missing persist-credentials: false on checkout.
🛡️ Proposed fix
check-latest:
runs-on: ubuntu-latest
+ permissions:
+ contents: read
outputs:
is_latest: ${{ steps.latest.outputs.is_latest }}
steps:
- name: Checkout
uses: actions/checkout@v5
with:
fetch-depth: 0
+ persist-credentials: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| check-latest: | |
| runs-on: ubuntu-latest | |
| outputs: | |
| is_latest: ${{ steps.latest.outputs.is_latest }} | |
| steps: | |
| - name: Checkout | |
| uses: actions/checkout@v5 | |
| with: | |
| fetch-depth: 0 | |
| check-latest: | |
| runs-on: ubuntu-latest | |
| permissions: | |
| contents: read | |
| outputs: | |
| is_latest: ${{ steps.latest.outputs.is_latest }} | |
| steps: | |
| - name: Checkout | |
| uses: actions/checkout@v5 | |
| with: | |
| fetch-depth: 0 | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 14-17: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[warning] 9-25: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block
(excessive-permissions)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/netlify-deploy.yaml around lines 9 - 17, The check-latest
job currently relies on inherited token permissions and checkout may persist
credentials unnecessarily. Update the check-latest job in the netlify-deploy
workflow to explicitly use least-privilege permissions for its read-only git
history access, and set persist-credentials to false on the actions/checkout@v5
step. Keep the change scoped to the check-latest job and its Checkout step.
Source: Linters/SAST tools
| - name: Determine if this deploy is for the latest release | ||
| id: latest | ||
| run: | | ||
| if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then | ||
| echo "is_latest=true" >> "$GITHUB_OUTPUT" | ||
| else | ||
| echo "is_latest=$(bash scripts/is_latest_tag.sh ${{ github.ref_name }})" >> "$GITHUB_OUTPUT" | ||
| fi |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Template injection: github.ref_name interpolated directly into run:.
Same issue as build-release.yaml — a crafted tag name containing shell metacharacters can inject commands into this runner. Route it through env: instead.
🔒️ Proposed fix
- name: Determine if this deploy is for the latest release
id: latest
+ env:
+ REF_NAME: ${{ github.ref_name }}
run: |
if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
echo "is_latest=true" >> "$GITHUB_OUTPUT"
else
- echo "is_latest=$(bash scripts/is_latest_tag.sh ${{ github.ref_name }})" >> "$GITHUB_OUTPUT"
+ echo "is_latest=$(bash scripts/is_latest_tag.sh "$REF_NAME")" >> "$GITHUB_OUTPUT"
fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Determine if this deploy is for the latest release | |
| id: latest | |
| run: | | |
| if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then | |
| echo "is_latest=true" >> "$GITHUB_OUTPUT" | |
| else | |
| echo "is_latest=$(bash scripts/is_latest_tag.sh ${{ github.ref_name }})" >> "$GITHUB_OUTPUT" | |
| fi | |
| - name: Determine if this deploy is for the latest release | |
| id: latest | |
| env: | |
| REF_NAME: ${{ github.ref_name }} | |
| run: | | |
| if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then | |
| echo "is_latest=true" >> "$GITHUB_OUTPUT" | |
| else | |
| echo "is_latest=$(bash scripts/is_latest_tag.sh "$REF_NAME")" >> "$GITHUB_OUTPUT" | |
| fi |
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 9-25: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block
(excessive-permissions)
[error] 24-24: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/netlify-deploy.yaml around lines 18 - 25, The
latest-release check in the Netlify workflow is interpolating github.ref_name
directly inside the shell script, which creates a template-injection risk.
Update the “Determine if this deploy is for the latest release” step in the
workflow to pass the tag name through env and reference that variable in the run
block instead of using direct interpolation, keeping the logic in the latest
step and the is_latest_tag.sh call unchanged otherwise.
Source: Linters/SAST tools
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/bump-version.yaml (1)
78-92: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueMinor duplication between master and rel/ commit paths.*
Both branches repeat
git add -A; git commit -m "Release ${NEW_VERSION}". Consider factoring the commit out before the conditional, leaving only branch creation/push logic to differ. Also considergit merge --ff-only "$RELEASE_BRANCH"on line 85 so a non-fast-forward scenario fails loudly instead of silently creating a merge commit.♻️ Suggested restructuring
if [ "$REF" = "master" ]; then RELEASE_BRANCH="rel/${NEW_VERSION}" git checkout -b "$RELEASE_BRANCH" - git add -A - git commit -m "Release ${NEW_VERSION}" + git add -A + git commit -m "Release ${NEW_VERSION}" git push origin "$RELEASE_BRANCH" git checkout master - git merge "$RELEASE_BRANCH" + git merge --ff-only "$RELEASE_BRANCH" git push origin master else # rel/* patch release: commit onto the maintenance branch, no master merge git add -A git commit -m "Release ${NEW_VERSION}" git push origin "HEAD:${REF}" fi🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/bump-version.yaml around lines 78 - 92, The release workflow in the branch handling around the master and rel/* paths duplicates the same add-and-commit steps. Refactor the common git add -A and git commit -m "Release ${NEW_VERSION}" into a single shared section before the conditional, and keep only the branch-specific checkout/push logic inside each branch. Also update the master merge in the release flow to use git merge --ff-only in the same workflow path so the release branch must fast-forward cleanly and fails instead of creating an unexpected merge commit.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/bump-version.yaml:
- Around line 78-92: The release workflow in the branch handling around the
master and rel/* paths duplicates the same add-and-commit steps. Refactor the
common git add -A and git commit -m "Release ${NEW_VERSION}" into a single
shared section before the conditional, and keep only the branch-specific
checkout/push logic inside each branch. Also update the master merge in the
release flow to use git merge --ff-only in the same workflow path so the release
branch must fast-forward cleanly and fails instead of creating an unexpected
merge commit.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 435ee12b-f8bb-4836-bfcc-1ed399f2228f
📒 Files selected for processing (5)
.github/workflows/build-release.yaml.github/workflows/bump-version.yaml.github/workflows/netlify-deploy.yamlMAINTENANCE.mdscripts/is_latest_tag.sh
✅ Files skipped from review due to trivial changes (1)
- scripts/is_latest_tag.sh
11e1a02 to
44038d3
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/bump-version.yaml:
- Around line 21-22: Update the release-branch validation and input guidance in
the bump-version workflow so patch releases only accept maintenance branches of
the form rel/X.Y.0. In the workflow logic that checks base_branch, tighten the
rel/* handling to require the trailing .0, and update the description text plus
any related validation/help strings to match the actual contract. Refer to the
base_branch input and the release-branch validation step in this workflow.
- Around line 87-96: The release refs are being published in separate git push
calls in the version bump workflow, which can leave the release commit partially
visible if a later push fails. Update the push logic in the bump-version job to
use a single atomic push for the release commit branch, the maintenance branch
created for master, and the version tag, so either all refs are published
together or none are.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 17c72af4-989d-4532-a163-b37ea340e7d3
📒 Files selected for processing (4)
.github/workflows/build-release.yaml.github/workflows/bump-version.yamlMAINTENANCE.mdscripts/is_latest_tag.sh
✅ Files skipped from review due to trivial changes (2)
- scripts/is_latest_tag.sh
- MAINTENANCE.md
44038d3 to
d16c33a
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
MAINTENANCE.md (1)
32-34: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd a language identifier to the fenced code block.
Flagged by markdownlint (MD040).
📝 Proposed fix
-``` +```shell gh workflow run build-release.yaml --ref master -f tag=vX.Y.Z -f make_latest=false</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@MAINTENANCE.mdaround lines 32 - 34, The fenced command in MAINTENANCE.md is
missing a language identifier, triggering markdownlint MD040. Update the code
block to use a shell-language fence for the gh workflow run command so the
fenced example is properly annotated and consistent with markdown linting rules.</details> <!-- cr-comment:v1:9fa28024b32aaba44c8234a9 --> _Source: Linters/SAST tools_ </blockquote></details> </blockquote></details> <details> <summary>🤖 Prompt for all review comments with AI agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.Nitpick comments:
In@MAINTENANCE.md:
- Around line 32-34: The fenced command in MAINTENANCE.md is missing a language
identifier, triggering markdownlint MD040. Update the code block to use a
shell-language fence for the gh workflow run command so the fenced example is
properly annotated and consistent with markdown linting rules.</details> --- <details> <summary>ℹ️ Review info</summary> <details> <summary>⚙️ Run configuration</summary> **Configuration used**: Organization UI **Review profile**: CHILL **Plan**: Pro **Run ID**: `f4499f2d-734d-4b78-9cc6-8721cec69988` </details> <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 44038d31fea589e8653bd73b0da40ceeeafc244b and d16c33ab0f4495b0eb1325a45fe923f98b39615f. </details> <details> <summary>📒 Files selected for processing (4)</summary> * `.github/workflows/build-release.yaml` * `.github/workflows/bump-version.yaml` * `MAINTENANCE.md` * `scripts/is_latest_tag.sh` </details> <details> <summary>🚧 Files skipped from review as they are similar to previous changes (2)</summary> * scripts/is_latest_tag.sh * .github/workflows/bump-version.yaml </details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
d16c33a to
c15ba81
Compare
Rework the release process into a single workflow that always runs from
master, so all release logic has one source of truth. Previously the
release relied on dispatching from a branch and on tag-push triggers,
both of which run the workflow file as it exists on that ref -- meaning
old rel/* branches would run stale release logic.
Release workflow (bump-version.yaml) is now an orchestrator, always run
from master:
- inputs: bump_type + base_branch (default master)
- major/minor require base_branch=master; patch requires a rel/X.Y.Z
branch (validated, fails fast otherwise)
- checks out base_branch, bumps, commits, and tags on it; for master
releases it also creates the long-lived rel/X.Y.0 maintenance branch
- computes whether the tag is the highest semver (is_latest_tag.sh) and
dispatches the downstream workflows from master via `gh workflow run
--ref master`, passing the tag and make_latest
This lets old LTS lines be patched by running the master workflow with
base_branch=rel/X.Y.0 -- needed now that we offer LTS support for CN /
on-prem deployments. Multiple patches accumulate on the same rel/X.Y.0
branch (bump_version.py increments from the branch's current version).
build-release.yaml switches from a tag-push trigger to workflow_dispatch
with tag + make_latest inputs, building the tagged code. Its filename is
unchanged, so PyPI trusted publishing (OIDC) needs no reconfiguration.
Old-line patches therefore publish to PyPI but produce a non-latest
GitHub release.
netlify-deploy.yaml reverts to a plain workflow_dispatch; the
orchestrator only dispatches it for the latest release, so old-line
patches skip docs.
scripts/is_latest_tag.sh reports whether a tag is the highest semver.
MAINTENANCE.md documents the master-orchestrated flow, the LTS patch
process, and the re-run escape hatch.
c15ba81 to
50ae8ba
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
MAINTENANCE.md (1)
40-42: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd language identifier to fenced code block.
Static analysis (MD040) flags the fenced block as missing a language spec.
📝 Proposed fix
-``` +```shell gh workflow run build-release.yaml --ref master -f tag=vX.Y.Z -f make_latest=false</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@MAINTENANCE.mdaround lines 40 - 42, The fenced command block in
MAINTENANCE.md is missing a language identifier and triggers MD040. Update that
fence to use a shell language specifier so the command under the workflow run
instructions is correctly marked up, and keep the existing gh workflow run
build-release.yaml example intact.</details> <!-- cr-comment:v1:b5e282f9940a4ad0e22dfab4 --> _Source: Linters/SAST tools_ </blockquote></details> </blockquote></details> <details> <summary>🤖 Prompt for all review comments with AI agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.Nitpick comments:
In@MAINTENANCE.md:
- Around line 40-42: The fenced command block in MAINTENANCE.md is missing a
language identifier and triggers MD040. Update that fence to use a shell
language specifier so the command under the workflow run instructions is
correctly marked up, and keep the existing gh workflow run build-release.yaml
example intact.</details> --- <details> <summary>ℹ️ Review info</summary> <details> <summary>⚙️ Run configuration</summary> **Configuration used**: Organization UI **Review profile**: CHILL **Plan**: Pro **Run ID**: `6c820add-439c-49ce-a0d5-209f35c03517` </details> <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between d16c33ab0f4495b0eb1325a45fe923f98b39615f and c15ba810d31f3f52b0ee87ed2551eaed747e6b45. </details> <details> <summary>📒 Files selected for processing (4)</summary> * `.github/workflows/build-release.yaml` * `.github/workflows/bump-version.yaml` * `MAINTENANCE.md` * `scripts/is_latest_tag.sh` </details> <details> <summary>🚧 Files skipped from review as they are similar to previous changes (2)</summary> * scripts/is_latest_tag.sh * .github/workflows/bump-version.yaml </details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
Summary
Reworks releasing into a single master-orchestrated workflow with one source of truth, and adds support for patching old (LTS) versions — needed now that we offer LTS support for CN / on-prem deployments.
Previously releasing took three manual steps, and the earlier consolidation still relied on dispatching from a branch and on tag-push triggers. Both run the workflow file as it exists on that ref, so old
rel/*branches would run stale release logic. This PR fixes that: the release workflow always runs frommaster.How it works
Release workflow (
bump-version.yaml) — always run frommaster:bump_type(major/minor/patch) +base_branch(defaultmaster).major/minorrequirebase_branch=master;patchrequires arel/X.Y.Zbranch (validated, fails fast otherwise).base_branch, bumps, commits, and tags on it. Formasterreleases it also creates the long-livedrel/X.Y.0maintenance branch.scripts/is_latest_tag.sh) and dispatches the downstream workflows from master viagh workflow run --ref master, passingtagandmake_latest.Because the workflow definition is always master's while
checkoutref:selects the code, the logic is centralized but can act on any line.LTS patching: merge the fix to master → cherry-pick onto
rel/X.Y.0→ run the Release workflow from master withbump_type=patch,base_branch=rel/X.Y.0. Patches accumulate on the same branch (bump_version.pyincrements from the branch's current version). Old-line patches publish to PyPI but produce a non-latest GitHub release and skip docs; patching the current latest line is correctly marked latest and deploys docs.build-release.yaml: switches from a tag-push trigger toworkflow_dispatchwithtag+make_latestinputs, building the tagged code. Filename unchanged → PyPI trusted publishing (OIDC) needs no reconfiguration. Also usable as a manual re-run escape hatch.netlify-deploy.yaml: plainworkflow_dispatch; the orchestrator only dispatches it for the latest release.MAINTENANCE.md: documents the master-orchestrated flow, LTS patch process, and the re-run escape hatch.Notes
TOKEN_GITHUB_YENKINS_ADMINPAT (the defaultGITHUB_TOKENcannot triggerworkflow_dispatch).rel/X.Y.0branch created once from their last tag before they can be patched — but the logic that runs is always master's.Summary by CodeRabbit
New Features
Bug Fixes
Documentation