Guard release workflow jobs from upstream failures

[juliusmarminge]

Summary

• Add failure and cancellation guards to the release workflow jobs so downstream publish steps do not run after an upstream job has already failed.
• Apply the same guard to the final release gate while preserving the stable-channel condition.
• Reduce the chance of partial or inconsistent release activity when the workflow is already in a failed state.

Testing

• Not run (workflow-only change).
• Reviewed the .github/workflows/release.yml diff to confirm the new if conditions were applied to build, publish_cli, release, and finalize.

---

Note

Low Risk
Workflow-only change that tightens job gating to prevent publish/release steps from running after upstream failures or cancellations. Low risk, with the main potential impact being inadvertently skipping jobs if conditions are mis-specified.

Overview
Adds explicit if: ${{ !failure() && !cancelled() }} guards to the release workflow’s downstream jobs (build, publish_cli, and release) so publish steps don’t run when an earlier job has already failed or the run was cancelled.

Updates the finalize gate to keep the stable-channel-only behavior while also requiring the overall workflow to be neither failed nor cancelled, reducing chances of partial/inconsistent release side effects.

^{Reviewed by Cursor Bugbot for commit 510350a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Guard release workflow jobs from upstream failures and cancellations

Adds if: ${{ !failure() && !cancelled() }} conditions to the build, publish_cli, and release jobs in release.yml, and extends the existing condition on the finalize job with the same guards. Without these conditions, GitHub Actions can run downstream jobs even when upstream jobs fail or the workflow is cancelled.

📊 Macroscope summarized 510350a. 1 file reviewed, 1 issue evaluated, 0 issues filtered, 1 comment posted

🗂️ Filtered Issues

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 74e875c3-db42-4d59-8594-b88a9cc8115f

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/guard-release-jobs

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

🔴 Critical workflows/release.yml:174

The if: ${{ !failure() && !cancelled() }} condition on build, publish_cli, and release allows these jobs to run when preflight is skipped — which happens on scheduled runs with no changes. When preflight is skipped, its outputs are empty, so build runs with empty version and ref values, cascading to broken releases. GitHub Actions' default success() would prevent this, but !failure() && !cancelled() is weaker and permits skipped upstream jobs. Consider adding && needs.preflight.result == 'success' to each job's if condition.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file .github/workflows/release.yml around line 174:

The `if: ${{ !failure() && !cancelled() }}` condition on `build`, `publish_cli`, and `release` allows these jobs to run when `preflight` is **skipped** — which happens on scheduled runs with no changes. When `preflight` is skipped, its outputs are empty, so `build` runs with empty `version` and `ref` values, cascading to broken releases. GitHub Actions' default `success()` would prevent this, but `!failure() && !cancelled()` is weaker and permits skipped upstream jobs. Consider adding `&& needs.preflight.result == 'success'` to each job's `if` condition.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issue. You can view the agent here.}

^{Reviewed by Cursor Bugbot for commit 510350a. Configure here.}

[cursor]

Guards allow jobs to run when preflight is skipped

High Severity

The if: ${{ !failure() && !cancelled() }} condition on build, publish_cli, and release replaces the default implicit success() check, which required all needed jobs to have succeeded. The failure() status function only returns true when a needed job has failed — it returns false when a needed job was skipped. On scheduled runs with no changes, preflight is skipped (not failed), so !failure() && !cancelled() evaluates to true and these jobs will incorrectly attempt to run with empty needs.preflight.outputs.* values. This would spin up build runners unnecessarily every 3 hours and produce confusing failures. Adding && needs.preflight.result == 'success' to each condition would preserve the intended guard while also filtering out the skipped case.

Additional Locations (2)

• .github/workflows/release.yml#L356-L357
• .github/workflows/release.yml#L391-L392

 

^{Reviewed by Cursor Bugbot for commit 510350a. Configure here.}

[cursor]

Bugbot Autofix determined this is a false positive.

All three jobs (build, publish_cli, release) already include needs.preflight.result == 'success' in their conditions, which correctly prevents execution when preflight is skipped.

_{You can send follow-ups to the cloud agent here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

1 blocking correctness issue found. Unresolved review comments identify a bug: the new guard conditions allow jobs to run when upstream jobs are skipped (not just failed), which could cause broken releases on scheduled runs. The suggested fix is to add && needs.preflight.result == 'success' to each condition.

^{You can customize Macroscope's approvability policy. Learn more.}