.github/workflows/release: fix cancellation handling and rollback condition

[lystopad]

Summary

Fix two related cancellation bugs in .github/workflows/release.yml:

1. Downstream jobs ignored cancellation. build-debian-pkg, publish-docker-image, and publish-release used if: always() && ..., which kept dispatching them onto runners even after the operator cancelled the workflow. The intermediate contains(needs.X.result, 'failure') checks did not match 'cancelled', and always() explicitly bypasses workflow-level cancellation.
2. Rollback skipped cancellations. In-case-of-failure enumerated specific failure modes (contains(..., 'failure') on each upstream) and required build-release.result == 'success'. Cancellations and skipped-due-to-upstream cases didn't satisfy any branch, so the git tag was left on the remote whenever the operator cancelled. The rollback step itself also assumed the tag was always present, so calling it on a workflow that never reached the tag-push step would emit a confusing "tag does not exist" failure.

Changes per job

build-release — no if: change

Always runs. Tag-push step (line 119) is still gated by inputs.perform_release && inputs.release_version != '', so a dry-run never creates a tag.

test-release — no if: change

Job-level if: remains ! inputs.skip_tests. Skipped tests yield result 'skipped', which downstream jobs continue to treat as a pass — same as before.

build-debian-pkg

-if: always() && contains(needs.build-release.result, 'success') && !contains(needs.test-release.result, 'failure')
+if: !cancelled() && contains(needs.build-release.result, 'success') && !contains(needs.test-release.result, 'failure')

• Full success: runs.
• test-release failed: skipped.
• test-release skipped (skip_tests=true): runs.
• build-release failed/cancelled: skipped.
• Workflow cancelled: skipped — was the bug; previously ran because 'cancelled' does not contain 'failure'.

publish-docker-image

Same change as build-debian-pkg, same behaviour matrix. Internal docker push step is additionally gated by inputs.perform_release for dry-run support.

publish-release

-if: always() && contains(... 'success') && contains(... 'success') && contains(... 'success')
+if: !cancelled() && contains(... 'success') && contains(... 'success') && contains(... 'success')

• Full success: runs.
• Any upstream failed/cancelled/skipped: skipped.
• Workflow cancelled in the window between all upstreams finishing as success and this job starting: skipped — was the bug.
• The internal gh release create step keeps its current set +e soft-failure behaviour intentionally: a half-published draft must be completable manually using the printed instructions and the already-built artefacts. The job is by design not allowed to fail. publish-release.result therefore stays 'success' even when the GitHub release object itself was not created, and rollback does not fire — preserving the tag and artefacts for the operator's manual recovery.

In-case-of-failure

Condition simplified from a four-branch failure-mode enumeration to a single positive invariant: roll back whenever the release did not fully publish.

 if: >-
   always() &&
   inputs.perform_release &&
-  contains(needs.build-release.result, 'success') &&
-  (
-    contains(needs.test-release.result, 'failure') ||
-    contains(needs.build-debian-pkg.result, 'failure') ||
-    contains(needs.publish-docker-image.result, 'failure') ||
-    contains(needs.publish-release.result, 'failure')
-  )
+  inputs.release_version != '' &&
+  needs.publish-release.result != 'success'

!= 'success' matches 'failure', 'cancelled', and 'skipped' uniformly. The build-release.result == 'success' precondition is removed so rollback also runs when build-release was cancelled mid-flight (the tag may already have been pushed at line 119 before the cancel signal arrived).

The rollback step is now idempotent via git ls-remote --exit-code --quiet --tags:

- git push -d origin ${RELEASE_VERSION}
+ if git ls-remote --exit-code --quiet --tags origin "${RELEASE_VERSION}"; then
+   git push -d origin "${RELEASE_VERSION}"
+   echo "Tag ${RELEASE_VERSION} removed."
+ else
+   echo "Tag ${RELEASE_VERSION} not present on remote — nothing to rollback."
+ fi

Behaviour matrix (assume perform_release=true unless noted)

Scenario	publish-release	rollback runs
Happy path	success	no
Dry run (perform_release=false)	success	no
skip_tests=true, otherwise success	success	no
build-release fails (tag may or may not exist)	skipped	yes
test-release fails	skipped	yes
build-debian-pkg fails	skipped	yes
publish-docker-image fails	skipped	yes
Cancel during build-release	skipped	yes
Cancel during test-release	skipped	yes
Cancel during build-debian-pkg	skipped	yes
Cancel during publish-docker-image	skipped	yes
Cancel during publish-release	cancelled	yes
Cancel after publish-release succeeded (too late)	success	no
gh release create fails (by design, soft-fail)	success	no
Operator cancels rollback itself	-	cancelled — tag may persist; manual cleanup

Step-level conditions left unchanged

• if: always() on the diagnostic torrent-client-status upload (test-release line 420). Step-level always() is contained to the job; it lets us capture diagnostics even when the QA test step itself failed.
• if: ${{ inputs.perform_release }} on the publish-side steps (lines 78, 113, 586, 627, 696). These gate API calls and tag creation for dry-run support.
• if: ${{ ! inputs.disable_version_check }} on the version validation step (line 164).

Test plan

• Dispatch with perform_release: false (dry run) — confirm all jobs run as before, no tag created, rollback not triggered.
• Dispatch with perform_release: true and let it complete normally — confirm release published, rollback not triggered.
• Dispatch with perform_release: true, cancel during test-release — confirm build-debian-pkg and publish-docker-image are skipped (not dispatched), rollback runs and removes tag.
• Dispatch with perform_release: true, cancel during build-debian-pkg — confirm publish-release is skipped, rollback runs and removes tag.
• Dispatch with perform_release: true against a non-existent commit/branch to force a build-release failure — confirm rollback runs and reports "nothing to rollback" (idempotent).

Cherry-pick to release/3.4 will follow once this is merged to main.

[Copilot]

Pull request overview

Updates the GitHub Actions release workflow to better respect operator cancellations and to make rollback behavior consistent when the release is not fully published.

Changes:

• Adjusts downstream job conditions to avoid dispatching jobs after a workflow cancellation.
• Simplifies rollback job condition to trigger whenever publishing did not complete successfully, and makes tag deletion idempotent.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[lystopad]

I tested it -- https://github.com/erigontech/erigon/actions/runs/25304335979/job/74177149288
Cancelation works.