feat: support release-x.y/{plugin} branches for Version Packages workflow

[lokanandaprabhu]

Summary

Adds release-*/* branch pattern to the Version Packages workflow trigger, so it fires on release-x.y/{plugin} branches (e.g. release-1.10/orchestrator) in addition to workspace/**.

Updates workspace name extraction to handle both branch formats:

• workspace/orchestrator → orchestrator
• release-1.10/orchestrator → orchestrator

The branch pattern is restricted to a single segment after the release prefix (release-*/* not release-*/**) and extraction uses cut -f2 (not cut -f2-) to ensure workspace names never contain slashes.

This removes the dependency on workspace/{plugin} as an intermediary branch for triggering Version Packages, enabling concurrent backports to different releases without conflicts on the shared workspace branch.

Ref: RHIDP-15922

Test plan

• Verify existing workspace/** branch PRs still trigger the workflow as before
• Create a test release-x.y/{plugin} branch, merge a PR into it, and verify Version Packages PR is created
• Verify workspace name is extracted correctly for both branch formats

🤖 Generated with Claude Code

[rhdh-qodo-merge]

PR Summary by Qodo

Support release-x.y/* branches in Version Packages workflow

✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Trigger Version Packages workflow on both workspace/** and release-*/** base branches.
• Extract workspace/plugin name correctly from either workspace/ or release-x.y/.
• Enable concurrent release backports without relying on shared workspace/ intermediary branches.

Diagram

graph TD
  pr(("PR closed")) --> wf["Workflow trigger"] --> check["Job: check-merged-pr"] --> dec{"Version Packages PR?"}
  baseRef["PR base.ref"] --> extract["Step: extract workspace"] --> name["workspace_name"]
  dec -- "no" --> changesets["Job: changesets-pr"]
  dec -- "yes" --> release["Job: release"]

  subgraph Legend
    direction LR
    _evt(("Event")) ~~~ _job["Job/Step"] ~~~ _dec{"Decision"}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Normalize branch parsing by stripping prefix up to first '/'

• ➕ Simplifies logic to a single extraction approach across branch families
• ➕ Naturally supports deeper paths (e.g., release-x.y/foo/bar) if that’s intended
• ➖ May change behavior for existing workspace branches if they ever include additional path segments (currently only takes the 2nd segment)
• ➖ Still benefits from explicit validation to avoid silently accepting unexpected formats

2. Fail fast on unexpected base refs

• ➕ Prevents running releases/changesets in the wrong workspace due to misparsed branch names
• ➕ Makes misconfiguration obvious when new branch conventions appear
• ➖ May require additional handling/documentation for any legitimate legacy branch formats

Recommendation: The PR’s approach (explicit pattern checks for workspace/* and release-*/*) is reasonable and easy to audit. Consider tightening it further by either (a) normalizing extraction via stripping everything before the first slash (and aligning workspace vs release behavior), and/or (b) failing fast when the base branch doesn’t match known patterns to avoid silently computing an incorrect workspace_name.

Files changed (1) +9 / -8

Other (1) +9 / -8

release_workspace_version.ymlTrigger workflow on release branches and parse workspace/plugin from base ref +9/-8

Trigger workflow on release branches and parse workspace/plugin from base ref

• Extends the pull_request trigger branches to include 'release-*/**' so the workflow runs on release-x.y plugin branches. Updates workspace name extraction to handle both 'workspace/<plugin>' and 'release-x.y/<plugin>' base branch formats before running changesets or release jobs.

.github/workflows/release_workspace_version.yml

[rhdh-qodo-merge]

Code Review by Qodo

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

1. Release workspace parsed as path ✓ Resolved 🐞 Bug ≡ Correctness

Description

For release-* base branches, the extraction uses cut -f2-, so any additional / in the base ref
yields a workspace_name containing slashes (e.g. foo/bar). That value is then used as
./workspaces/${workspace_name} and in scripts that chdir into workspaces/${WORKSPACE_NAME},
causing the workflow to fail when the directory doesn’t exist.

Code

.github/workflows/release_workspace_version.yml[R46-48]

+              elif [[ "$BASE_REF" == release-*/* ]]; then
+                WORKSPACE_NAME=$(echo "$BASE_REF" | cut -d'/' -f2-)
+              else

Relevance

●●● Strong

Likely accepted: workflow-name/path hardening to prevent CI failures; similar robustness fixes were
accepted previously.

PR-#2764

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow accepts release branches and extracts workspace_name from the base ref; if that
extracted value contains additional path segments, it is used as a directory name under
workspaces/ and as the workspace directory for node scripts, which will fail unless the repo
actually contains nested workspace directories.

.github/workflows/release_workspace_version.yml[7-10]
.github/workflows/release_workspace_version.yml[39-51]
.github/workflows/release_workspace_version.yml[58-61]
scripts/ci/check-if-release.js[60-73]
scripts/ci/create-tag.js[60-78]

Agent prompt

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

### Issue description
The workflow can derive a multi-segment `workspace_name` (containing `/`) from release branch names, but downstream steps assume `workspace_name` is a single directory name under `workspaces/`.

### Issue Context
- The workflow trigger now includes `release-*/**`.
- The extraction logic uses `cut -d'/' -f2-` for release branches, preserving additional path segments.
- `workspace_name` is used in `defaults.run.working-directory: ./workspaces/${{ ... }}` and in node scripts that `chdir` into `workspaces/<WORKSPACE_NAME>`.

### Fix Focus Areas
- .github/workflows/release_workspace_version.yml[7-10]
- .github/workflows/release_workspace_version.yml[39-51]
- .github/workflows/release_workspace_version.yml[58-61]

### Recommended change
1. Constrain the intended release branch shape in the workflow trigger (e.g. `release-*/*` if the intended format is exactly `release-x.y/<plugin>`).
2. Extract only the plugin/workspace segment for release branches (use `cut -d'/' -f2`), and/or explicitly validate that the extracted `WORKSPACE_NAME` does not contain `/` and that `workspaces/$WORKSPACE_NAME` exists; fail fast with a clear error if not.

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

---

Context used

⚠️ 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

  Not relevant to this PR: redhat-developer/rhdh

  Not relevant to this PR: redhat-developer/rhdh-chart

  Not relevant to this PR: redhat-developer/rhdh-operator

  Not relevant to this PR: redhat-developer/rhdh-local

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[karthikjeeyar]

Merging a PR into workspace/* or release-*/* currently triggers a Version Packages PR off a shared branch named maintenance-changesets-release/<workspace-name>. This still creates collisions when backporting to different versions concurrently (e.g., release-1.5/my-plugin and release-1.6/my-plugin).

Check this PR - #4101 which is created from a maintenance branch.

To support concurrent backports without branch conflicts, we need to include the release target in the branch name: maintenance-changesets-release/release-*/<workspace-name> as well.

[lokanandaprabhu]

@karthikjeeyar ,

Updated the PR — the versionBranch now includes the full base ref for release-*/* branches, so concurrent backports get unique branch names:

workspace/orchestrator → maintenance-changesets-release/orchestrator (unchanged)
release-1.10/orchestrator → maintenance-changesets-release/release-1.10/orchestrator
release-1.5/orchestrator → maintenance-changesets-release/release-1.5/orchestrator

[karthikjeeyar]

Thanks @lokanandaprabhu, Could you also update the Contibuting guide to reflect this new change wrt release-* which supports concurrent backports?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[lokanandaprabhu]

@karthikjeeyar I have updated the contribution guide and kept the old flow as legacy and new flow as recommended. PTAL.

[karthikjeeyar]

Looks good to me!