feat(ci): update prior release workflow

[hopehadfield]

Hey, I just made a Pull Request!

Addresses https://redhat.atlassian.net/browse/RHIDP-16860

Updates the prior-release workflow to support the new repository-wide release-2.1+ model while preserving the legacy per-plugin release-1.9/1.10/<workspace> flow.

Changes

• Split release handling into explicit legacy and repository-wide paths.
• Added repository-wide workspace detection and matrix processing for multiple changed workspaces.
• Kept legacy branch-based workspace detection for 1.x release branches.
• Added safeguards for:
  • Merged pull requests only.
  • Existing Version Packages branch collisions.
  • Correct release-branch/workspace identifiers.
  • Valid pinned actions/cache usage.
• Documented:
  • The 1.x legacy backport process.
  • The 2.1+ repository-wide backport process.
  • Feature Freeze release-branch creation.
• Updated workflow documentation in .github/workflows/README.md.

The duplication is intentional because the legacy 1.x and repository-wide 2.1+ workflows use different branch structures, workspace discovery, and release handling. Keeping the paths separate also avoids introducing unnecessary breakage through a broad refactor during the transition; the legacy path can be removed after 1.x reaches EOL.

Validation

Tested in my personal fork with no package publication or tag creation:

• 2.1 single-workspace flow.
• 1.10 legacy per-plugin flow.
• 2.1 multi-workspace flow with separate homepage and augment changesets.
• Confirmed separate Version Packages branches and PRs were created for both workspaces.
• Confirmed unrelated workflow paths were skipped.
• actionlint, Prettier validation, and git diff --check passed for the production changes.

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or Updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)

[rhdh-qodo-merge]

PR Summary by Qodo

Support repository-wide prior releases for 2.x branches

✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 40+ Minutes

AI Description

• Splits prior releases between legacy 1.x and repository-wide 2.x branch models.
• Detects changed workspaces and creates isolated Version Packages pull requests in parallel.
• Documents supported backport branches, safeguards, publishing, and tagging behavior.

Diagram

graph TD
  PR["Merged PR"] --> C{"Release path"}
  C -->|Legacy| L["Legacy workspace"] --> V["Version PR"]
  C -->|Repository| D["Workspace detector"] --> M["Matrix jobs"] --> V
  V -->|Merged| P["Maintenance publish"] --> T["Git tag"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Separate legacy and repository workflows

• ➕ Simplifies each workflow's triggers and conditional logic.
• ➕ Allows independent maintenance and retirement of the legacy path.
• ➖ Duplicates validation, setup, publishing, and tagging behavior.
• ➖ Increases the risk that release safeguards drift between workflows.

2. Reusable workspace release workflow

• ➕ Centralizes repeated installation, build, publish, and tagging steps.
• ➕ Keeps legacy and repository-wide publishing behavior consistent.
• ➖ Requires additional workflow inputs, secret forwarding, and context handling.
• ➖ Adds migration risk to an already release-critical change.

Recommendation: Retain the PR's explicit routing and matrix-based repository flow for this rollout because it preserves legacy behavior while introducing the new branch model atomically. After the repository-wide path is proven, extracting the duplicated build-and-publish sequence into a reusable workflow would reduce long-term maintenance without complicating this migration.

Files changed (4) +313 / -103

Enhancement (1) +3 / -1

list-workspaces-with-changes.jsMake the noop workspace optional +3/-1

Make the noop workspace optional

• Adds the INCLUDE_NOOP environment switch so release workflows can return an empty workspace list when no real workspace changed. Existing callers retain the default noop fallback.

scripts/ci/list-workspaces-with-changes.js

Documentation (2) +29 / -44

README.mdDocument prior-version workflow branch models +11/-0

Document prior-version workflow branch models

• Adds an overview of the legacy per-plugin release flow and the repository-wide 2.x flow. It explains Version Packages PR creation, maintenance publishing, and supported branch conventions.

.github/workflows/README.md

CONTRIBUTING.mdDefine legacy and repository-wide backport procedures +18/-44

Define legacy and repository-wide backport procedures

• Replaces the deprecated workspace-branch guidance with separate instructions for legacy 1.x per-plugin branches and repository-wide 2.1+ branches. Documents branch creation, Version Packages PRs, maintenance publishing, and tagging expectations.

CONTRIBUTING.md

Other (1) +281 / -58

release_workspace_version.ymlAdd repository-wide prior-release orchestration +281/-58

Add repository-wide prior-release orchestration

• Classifies supported release branches and validates merged bot-authored Version Packages PRs before running release jobs. Adds changed-workspace detection, per-workspace matrix PR generation, collision checks, concurrency controls, and a dedicated repository-wide publish path while retaining legacy 1.x releases.

.github/workflows/release_workspace_version.yml

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Unsupported 2.0 releases run 🐞 Bug ≡ Correctness

Description

classify_branch treats every repository-wide branch with major version 2 or greater as supported,
including release-2.0, although the new release model begins at 2.1. A merged pull request
targeting release-2.0 therefore reaches workspace detection and Version Packages creation under an
unsupported release model.

Code

.github/workflows/release_workspace_version.yml[R61-63]

+            if (( RELEASE_MAJOR >= 2 )); then
+              echo "is_repository_release=true" >> "$GITHUB_OUTPUT"
+              echo "is_supported_branch=true" >> "$GITHUB_OUTPUT"

Relevance

●●● Strong

Supported release boundaries are explicit; recent workflow bug fixes in this file were accepted.

PR-#4173

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The classifier enables the repository-wide path solely when the captured major number is at least 2.
Both workflow documentation and contributor instructions explicitly state that repository-wide
releases start at release-2.1, proving that release-2.0 should not pass this guard.

.github/workflows/release_workspace_version.yml[59-68]
.github/workflows/README.md[15-20]
CONTRIBUTING.md[129-132]
CONTRIBUTING.md[183-185]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Repository-wide release handling is documented as starting with release 2.1, but branch classification accepts release 2.0 because it checks only that the major version is at least 2.

## Fix Focus Areas
- .github/workflows/release_workspace_version.yml[59-68]

## Recommended Fix
Capture both major and minor versions and classify a repository-wide branch as supported only when the major version is greater than 2, or when the major version is 2 and the minor version is at least 1. Keep later major release lines supported.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

✅ Compliance rules (platform): 11 rules

✅ Cross-repo context — repo relationships

Review mode: ⚖️ Balanced: Downgraded extended -> standard: change is below the extended eligibility bar (hunks 12/18, lines 416/200; both must reach the floor). Router rationale: This substantially modifies a security-sensitive, release/publishing CI workflow with multiple independent legacy and repository-wide paths, matrix logic, branch classification, and npm publication behavior, creating a dense set of easy-to-miss failure modes.

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[rhdh-qodo-merge]

Important

The /generate_labels command by Qodo is sunsetting on the 1st of October 2026 and will no longer be available. We recommend switching to the latest Qodo review capabilities. Learn more

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[hopehadfield]

Lifecycle scripts must remain enabled in the publish job because the release build depends on native package bindings. There is no risk here because the job only runs for merged, bot-created Version Packages PRs.

[lokanandaprabhu]

Looks mostly good to me — thanks for splitting the legacy 1.x release-1.x/{plugin} path from the 2.1+ repository-wide release-x.y flow.

One question on the old workspace/* path: this PR removes workspace/** from the workflow on main, but existing workspace/<plugin> branches still carry the old release_workspace_version.yml. GitHub runs that file from the target branch, so a manual backport merged into workspace/<plugin> can still open Version Packages even after this lands.

How do we want to handle that?

sync the updated workflow onto those branches so they no longer trigger Prior Version Release or delete them after confirming nothing is pending in those branches?