fix(ci): gate the release notes backfill behind reviewer approval

[sfreudenthaler]

Closes: #37139

Top of stack #37143. Based on #37141.

Problem

cicd_ai-release-notes-backfill.yml ends in an unconditional replace on a public release body:

gh release edit "$RELEASE_TAG" --notes-file /tmp/release-notes.md

It overwrites hand edits and cannot be undone from the workflow.

workflow_dispatch is limited to accounts with write access — never forks, never anonymous users — but that is 45 accounts on this repo. Since this workflow shipped in March 2026 it has been an unreviewed write path to public release documentation, for any release tag, by any of those accounts.

Fix

A no-op approval gate on the release-notes-backfill environment (required_reviewers: dotDevelopers), with the generate job needs: gate. Same pattern as cicd_evergreen-tracks-promote.yml's apply gate and the changelog-site-publish gate in #37141.

The environment has been created with that rule. If it is ever removed, GitHub auto-creates a missing environment unprotected on first use, silently removing the gate — it fails open, not closed. The workflow comment says so at the gate.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EbgDBJuoBrpJxh5qLMPorL

[claude]

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

---

Review

Checked the diff against the referenced cicd_evergreen-tracks-promote.yml gate pattern and the full workflow file.

The gate is correctly wired. release-notes declares needs: gate with no always()/if override, so a rejected or failed gate short-circuits the generate job — the gh release edit replace never runs without approval. Unlike cicd_evergreen-tracks-promote.yml (which needs needs.gate.result == 'success' || 'skipped' to accommodate its unattended cron path), this workflow is workflow_dispatch-only, so the stricter plain needs: gate is the right choice here — there's no scheduled path where the gate would be skipped.

The fail-open caveat and the cancel-in-progress interaction raised earlier are both accurate and correctly scoped out: fail-open is a GitHub environment behavior not fixable in-repo (the gate comment documents it), and a cancelled backfill writes nothing, so the pre-existing concurrency setting is harmless. No action needed on either.

New Issues

• 🟡 Medium: .github/workflows/cicd_ai-release-notes-backfill.yml:46-47 — the new run: step interpolates ${{ inputs.release_tag }} / ${{ inputs.previous_tag }} directly into the shell script, which is the GitHub Actions script-injection shape. Assumption: workflow_dispatch inputs are settable only by accounts with write access (as the PR notes), and this step is a no-op echo with no secrets in scope, so there is no privilege boundary crossed — impact is low. What to verify: if you want to match GitHub's recommended convention regardless, pass the values via env: and reference "$RELEASE_TAG" in the script rather than inlining the expression. Non-blocking. Fix this →

Otherwise clean — the change does exactly what it claims: adds a no-op approval gate ahead of the notes rewrite.

· 37139-gate-notes-backfill

[sfreudenthaler]

No code changes needed here — the review found no issues, and its one note was a verification request rather than a defect.

Confirming it: the release-notes-backfill environment exists with the protection rule, created before this PR was opened and re-verified just now via gh api /repos/dotCMS/core/environments/release-notes-backfill:

required_reviewers -> dotDevelopers

So the gate is real, not pending setup.

Two points from the review worth keeping on the record:

• The fail-open behavior is correctly identified and is not fixable in-repo. If the environment is deleted, GitHub recreates it unprotected on first use and the gate silently passes. The comment at the gate says so; there is no workflow-level assertion that can catch it.
• The pre-existing cancel-in-progress: true means a run parked on approval can be cancelled by a newer dispatch for the same tag. Unchanged by this PR and harmless here — a cancelled backfill writes nothing — so leaving it as-is rather than widening scope.