Skip to content

chore: support manually triggering against a workspace + branch (eg., for when orchestrator-1.9 needs an update); also do the prior version release step if needs.check-merged-pr.outputs.needs_release is true#2467

Open
nickboldt wants to merge 1 commit intomainfrom
allow-override-push-to-branch
Open

chore: support manually triggering against a workspace + branch (eg., for when orchestrator-1.9 needs an update); also do the prior version release step if needs.check-merged-pr.outputs.needs_release is true#2467
nickboldt wants to merge 1 commit intomainfrom
allow-override-push-to-branch

Conversation

@nickboldt
Copy link
Member

What does this PR do?

chore: support manually triggering against a workspace + branch (eg., for when orchestrator-1.9 needs an update); also do the prior version release step if needs.check-merged-pr.outputs.needs_release is true

Signed-off-by: Nick Boldt nboldt@redhat.com

Screenshot/screencast of this PR

N/A

What issues does this PR fix or reference?

N/A (or see commit message above for issue number)

How to test this PR?

N/A

PR Checklist

As the author of this Pull Request I made sure that:

  • Code produced is complete
  • Code builds without errors
  • Tests are covering the bugfix
  • Relevant user documentation updated
  • Relevant contributing documentation updated

Reviewers

Reviewers, please comment how you tested the PR when approving it.

… for when orchestrator-1.9 needs an update); also do the prior version release step if needs.check-merged-pr.outputs.needs_release is true

Signed-off-by: Nick Boldt <nboldt@redhat.com>
@nickboldt nickboldt requested review from a team as code owners March 5, 2026 14:37
@nickboldt nickboldt changed the title chore: support manually triggering against a... chore: support manually triggering against a workspace + branch (eg., for when orchestrator-1.9 needs an update); also do the prior version release step if needs.check-merged-pr.outputs.needs_release is true Mar 5, 2026
@rhdh-qodo-merge
Copy link

Review Summary by Qodo

Support manual workflow dispatch for workspace version releases

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Add manual workflow dispatch trigger with workspace, branch, and force_release inputs
• Skip release check when force_release is true to allow manual overrides
• Trigger release job when force_release is enabled or needs_release is true
• Enable manual control over workspace version releases independent of PR events
Diagram
flowchart LR
  A["workflow_dispatch inputs<br/>workspace, branch, force_release"] -->|"manual trigger"| B["release_workspace_version workflow"]
  C["pull_request closed event"] -->|"automatic trigger"| B
  B -->|"force_release=true"| D["Skip release check"]
  B -->|"force_release=false"| E["Run release check"]
  D -->|"proceed"| F["Update Version Packages PR"]
  E -->|"needs_release=true"| F
  F -->|"version PR created"| G["Release job"]
  D -->|"or force_release=true"| G
Loading

Grey Divider

File Changes

1. .github/workflows/release_workspace_version.yml ✨ Enhancement +18/-2

Add manual dispatch trigger and force release override

• Added workflow_dispatch trigger with three inputs: workspace (required), force_release
 (optional boolean), and branch (required)
• Modified release check step to skip when force_release is true, allowing manual override of
 automatic release detection
• Updated changesets-pr condition to create PR when release is needed OR force_release is not true
• Enhanced release job condition to trigger when version PR exists OR needs_release is true OR
 force_release is enabled

.github/workflows/release_workspace_version.yml


Grey Divider

Qodo Logo

@rhdh-qodo-merge
Copy link

rhdh-qodo-merge bot commented Mar 5, 2026

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 📎 Requirement gaps (0)

Grey Divider


Action required

1. Manual dispatch will fail 🐞 Bug ⛯ Reliability
Description
workflow_dispatch was added, but the workflow’s first job still unconditionally reads
github.event.pull_request.*, which does not exist for manual runs. As a result, manually
triggering the workflow will fail or compute empty outputs, and the new workspace/branch inputs
are not wired into the job logic.
Code

.github/workflows/release_workspace_version.yml[R4-18]

+  workflow_dispatch:
+    inputs:
+      workspace:
+        description: 'Name of the Workspace'
+        required: true
+        type: string
+      force_release:
+        description: 'Force release even if no changesets are present'
+        required: false
+        type: boolean
+      branch:
+        description: 'Branch to run the workflow on'
+        required: true
+        default: ''
+        type: string
Evidence
The workflow declares workflow_dispatch inputs, but check-merged-pr uses
github.event.pull_request.* and extracts the workspace from the PR base ref; those fields are
absent in workflow_dispatch events, so the manual trigger path cannot succeed as implemented.

.github/workflows/release_workspace_version.yml[3-18]
.github/workflows/release_workspace_version.yml[34-65]

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

## Issue description
Manual `workflow_dispatch` runs will fail because the workflow assumes a `pull_request` event payload (`github.event.pull_request.*`) even when triggered manually. The newly added `workspace`/`branch` inputs are not integrated into the job logic.

## Issue Context
This workflow is now triggered by both `pull_request: closed` and `workflow_dispatch`. For `workflow_dispatch`, there is no `pull_request` object in the event payload.

## Fix Focus Areas
- .github/workflows/release_workspace_version.yml[3-66]
- .github/workflows/release_workspace_version.yml[67-90]
- .github/workflows/release_workspace_version.yml[150-167]

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


2. Release checks wrong output 🐞 Bug ✓ Correctness
Description
The release job condition references needs.check-merged-pr.outputs.needs_release, but
check-merged-pr does not output needs_release. This makes the new “run release when
needs_release is true” behavior non-functional.
Code

.github/workflows/release_workspace_version.yml[154]

+    if: needs.check-merged-pr.outputs.is_version_pr == 'true' || needs.check-merged-pr.outputs.needs_release == 'true' || inputs.force_release == true
Evidence
needs_release is produced (as a job output) by changesets-pr, not by check-merged-pr. The
release job currently only needs: check-merged-pr and checks a non-existent output key, so the
condition cannot ever be true due to needs_release.

.github/workflows/release_workspace_version.yml[37-40]
.github/workflows/release_workspace_version.yml[78-80]
.github/workflows/release_workspace_version.yml[150-155]
.github/workflows/release_workspace.yml[105-110]

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 `release` job checks `needs.check-merged-pr.outputs.needs_release`, but that output does not exist on `check-merged-pr`. As a result, the new release gating will never trigger based on `needs_release`.

## Issue Context
`needs_release` is currently exported by the `changesets-pr` job, not `check-merged-pr`. The `release` job must either depend on `changesets-pr` or compute/export `needs_release` elsewhere.

## Fix Focus Areas
- .github/workflows/release_workspace_version.yml[67-80]
- .github/workflows/release_workspace_version.yml[150-156]

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


3. Wrong changesets if logic 🐞 Bug ✓ Correctness
Description
The updated condition for the changesets-action step uses || inputs.force_release != true, which
causes the PR-creation step to run when needs_release is 'true' but force_release is false.
This defeats the intent of skipping PR creation when version bumps (and thus a release) are already
detected.
Code

.github/workflows/release_workspace_version.yml[139]

+        if: steps.release_check.outputs.needs_release != 'true' || inputs.force_release != true
Evidence
check-if-release.js sets needs_release=true when version bumps are detected. With the current OR
condition, if needs_release == 'true' and force_release is false/unset, the right-hand clause
(inputs.force_release != true) evaluates to true, making the overall expression true and
incorrectly running the changesets PR step.

scripts/ci/check-if-release.js[133-146]
.github/workflows/release_workspace_version.yml[125-140]

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 changesets-action step gating logic is incorrect. It will run when `needs_release` is `&#x27;true&#x27;` and `force_release` is not true, which is the opposite of the intended behavior (skip PR creation when a release is already needed).

## Issue Context
`check-if-release.js` explicitly emits `needs_release=true` when version bumps are present.

## Fix Focus Areas
- .github/workflows/release_workspace_version.yml[125-146]
- scripts/ci/check-if-release.js[133-147]

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



Remediation recommended

4. Forced release empties output 🐞 Bug ⛯ Reliability
Description
When force_release is true, the release_check step is skipped, but the job still exports
needs_release from that step. This produces an empty output value, which can lead to incorrect
downstream gating when consumers expect 'true'/'false'.
Code

.github/workflows/release_workspace_version.yml[R126-130]

        id: release_check
+        if: inputs.force_release != true
        run: |
          yarn install
          node scripts/ci/check-if-release.js
Evidence
The job-level output is always read from steps.release_check.outputs.needs_release, but that step
is conditional and may not run. In GitHub Actions, skipped step outputs resolve to empty strings,
which is fragile for conditions and for debugging.

.github/workflows/release_workspace_version.yml[78-80]
.github/workflows/release_workspace_version.yml[125-128]

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

## Issue description
When `force_release` is enabled, the step that produces `needs_release` is skipped, resulting in an empty string output.

## Issue Context
Downstream conditions typically compare outputs to `&#x27;true&#x27;`/`&#x27;false&#x27;`, and an empty string can silently change behavior.

## Fix Focus Areas
- .github/workflows/release_workspace_version.yml[78-80]
- .github/workflows/release_workspace_version.yml[125-136]

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


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

@sonarqubecloud
Copy link

sonarqubecloud bot commented Mar 5, 2026

Copy link
Member

@lholmquist lholmquist left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure :)

Comment on lines +4 to +18
workflow_dispatch:
inputs:
workspace:
description: 'Name of the Workspace'
required: true
type: string
force_release:
description: 'Force release even if no changesets are present'
required: false
type: boolean
branch:
description: 'Branch to run the workflow on'
required: true
default: ''
type: string

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Manual dispatch will fail 🐞 Bug ⛯ Reliability

workflow_dispatch was added, but the workflow’s first job still unconditionally reads
github.event.pull_request.*, which does not exist for manual runs. As a result, manually
triggering the workflow will fail or compute empty outputs, and the new workspace/branch inputs
are not wired into the job logic.
Agent Prompt
## Issue description
Manual `workflow_dispatch` runs will fail because the workflow assumes a `pull_request` event payload (`github.event.pull_request.*`) even when triggered manually. The newly added `workspace`/`branch` inputs are not integrated into the job logic.

## Issue Context
This workflow is now triggered by both `pull_request: closed` and `workflow_dispatch`. For `workflow_dispatch`, there is no `pull_request` object in the event payload.

## Fix Focus Areas
- .github/workflows/release_workspace_version.yml[3-66]
- .github/workflows/release_workspace_version.yml[67-90]
- .github/workflows/release_workspace_version.yml[150-167]

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

runs-on: ubuntu-latest
needs: check-merged-pr
if: needs.check-merged-pr.outputs.is_version_pr == 'true'
if: needs.check-merged-pr.outputs.is_version_pr == 'true' || needs.check-merged-pr.outputs.needs_release == 'true' || inputs.force_release == true

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Release checks wrong output 🐞 Bug ✓ Correctness

The release job condition references needs.check-merged-pr.outputs.needs_release, but
check-merged-pr does not output needs_release. This makes the new “run release when
needs_release is true” behavior non-functional.
Agent Prompt
## Issue description
The `release` job checks `needs.check-merged-pr.outputs.needs_release`, but that output does not exist on `check-merged-pr`. As a result, the new release gating will never trigger based on `needs_release`.

## Issue Context
`needs_release` is currently exported by the `changesets-pr` job, not `check-merged-pr`. The `release` job must either depend on `changesets-pr` or compute/export `needs_release` elsewhere.

## Fix Focus Areas
- .github/workflows/release_workspace_version.yml[67-80]
- .github/workflows/release_workspace_version.yml[150-156]

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

- name: Update Version Packages (${{ needs.check-merged-pr.outputs.workspace_name }}) PR
id: changesets-pr
if: steps.release_check.outputs.needs_release != 'true'
if: steps.release_check.outputs.needs_release != 'true' || inputs.force_release != true

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

3. Wrong changesets if logic 🐞 Bug ✓ Correctness

The updated condition for the changesets-action step uses || inputs.force_release != true, which
causes the PR-creation step to run when needs_release is 'true' but force_release is false.
This defeats the intent of skipping PR creation when version bumps (and thus a release) are already
detected.
Agent Prompt
## Issue description
The changesets-action step gating logic is incorrect. It will run when `needs_release` is `'true'` and `force_release` is not true, which is the opposite of the intended behavior (skip PR creation when a release is already needed).

## Issue Context
`check-if-release.js` explicitly emits `needs_release=true` when version bumps are present.

## Fix Focus Areas
- .github/workflows/release_workspace_version.yml[125-146]
- scripts/ci/check-if-release.js[133-147]

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants