[sfreudenthaler]

Proposed Changes

• changelog-site-publish in cicd_6-release.yml now runs when release-notes was cancelled. Its if: gains !cancelled() plus explicit checks that release-prepare and deployment succeeded and that release-notes was not skipped.
• Before: the if: had no status function, so GitHub's implicit success() skipped the publish whenever release-notes was cancelled, with no notice. This happened in Release 26.10.28-01 (run 40712120594), where a runner blip killed the release-notes checkout after about 9s.

release ──► release-notes ──► changelog-site-publish ──► evergreen-site-sync
            (allow_failure)

release-notes   │ before                          │ after
────────────────┼─────────────────────────────────┼─────────────────────────────────
success         │ publish runs                    │ publish runs (unchanged)
failed          │ publish runs → fails on empty   │ unchanged
                │ body → Slack "publish FAILED"   │
cancelled       │ publish SKIPPED, no notice →    │ publish runs → fails on empty body
                │ evergreen sync fails later with │ → Slack "publish FAILED" names the
                │ "no release row" (wrong lead)   │ backfill workflow
skipped         │ publish skipped                 │ publish skipped (release failed)

Nothing new gets published on the cancelled path: the publish phase still refuses an empty release body. The only change is that the failure is now reported at the step that actually broke.

Checklist

• Tests (workflow-only change; the if: was checked by parsing the YAML)
• Security Implications Contemplated (no new secrets, permissions or triggers)

Additional Info

Run AI Release Notes (Backfill) for the release afterwards: it regenerates the notes and republishes the changelog row.

Closes: #38342

🤖 Generated with Claude Code

[claude]

Claude finished @sfreudenthaler's task in 2m 1s —— View job

---

Code Review

I reviewed the if: change on changelog-site-publish in .github/workflows/cicd_6-release.yml against the surrounding jobs (release-notes, deployment, evergreen-site-sync).

The logic is sound. Walking the four release-notes result states against the new condition confirms the table in the PR body:

release-notes.result	!cancelled()	!= 'skipped'	publish runs?
success	true	true	✅ runs
failure	true	true	✅ runs (fails loud on empty body)
cancelled	true	true	✅ runs
skipped	true	false	⛔ skipped

A few things I verified as correct and not bugs:

• !cancelled() in a >- folded scalar is safe. The ! would be a YAML tag indicator in a plain flow scalar, but inside the block scalar it's literal text handed to the GitHub expression engine — no parse error.
• !cancelled() doubles as the status-check function that lets GitHub evaluate the if: at all when the needed release-notes job is cancelled/failed (otherwise the dependent job is auto-skipped). Good.
• No regression vs. the old implicit success(): success() required all three needs to succeed; the explicit release-prepare.result == 'success' && deployment.result == 'success' preserves that for those two, and intentionally relaxes only release-notes.
• The skipped guard is coherent with release-notes's own if: success() (line 533): if release failed there's no GitHub release body to publish, so skipping is right.

New Issues

• 🟡 Medium: .github/workflows/cicd_6-release.yml:555 — the entire fix rests on cancelled() evaluating to false when release-notes is cancelled by a runner blip (as opposed to a user/API cancellation of the whole run). cancelled() is documented as run-scoped ("returns true if the workflow was cancelled"), so a single infrastructure-cancelled job should leave it false and the publish should run as intended — but this is the one behavior the PR was not exercised against (the checklist notes it was only validated by parsing the YAML).
  Assumption: a runner blip that cancels release-notes does not transition the run into a cancelled state.
  What to verify: before relying on this in production, confirm against a real cancelled-job run (e.g. re-examine run 40712120594, or force a cancel in a test workflow) that a downstream !cancelled() job actually executes. If GitHub flips run-level cancelled() to true on a dependency cancellation, this condition would still skip the publish and the fix would be a no-op for exactly the scenario it targets — in which case always() + an explicit needs.release-notes.result != 'cancelled'-aware condition would be needed instead.

Otherwise this is a clean, well-scoped, additive workflow change. Nothing blocking.

· issue-38342-changelog-publish-after-cancelled-notes