ci(github): auto-fire release after merge of 'PR: Release after merge' labeled PRs

[wezell]

Fixes #37383

Summary

Adds a new workflow, issue_release-after-merge.yml, that automatically fires the dotCMS release process when a PR labeled PR: Release after merge is merged into main.

How it works

1. Trigger: pull_request: closed with merged == true, base ref main, and the PR: Release after merge label present at merge time.
2. Version computation — release-aware, following the tag formula v{yy.mm.dd}-## (zero-padded two-digit counter, UTC date):
   • reads today's existing v{yy.mm.dd}-## tags via git ls-remote
   • scans cicd_6-release.yml runs queued or in flight, parsing their versions from run names (Release <version>), and steps over them (their tags don't exist yet)
   • picks max(tag counter, in-flight counter) + 1, re-verifying each candidate against the remote — important because release-prepare force-overwrites colliding tags/branches
3. Dispatch: gh workflow run cicd_6-release.yml --ref main with the computed release_version.
4. Observability: comments on the merged PR with the queued version and run URL (best-effort).

Design decisions

Decision	Rationale
Lives on pull_request: closed, not the merge queue	The merge queue runs before merge (validation gate); post-merge actions belong on the close lifecycle, like issue_post-pr-merge.yml
Dedicated concurrency group (auto-release-after-merge)	Serializes computation + dispatch so two labeled PRs merging simultaneously each get their own increment
Dispatch via CI_MACHINE_TOKEN	Events created with the default GITHUB_TOKEN do not trigger other workflow runs (recursive-workflow prevention) — a github.token dispatch would silently no-op
Gate on base.ref == 'main'	Mirrors the Release workflow's own verify-branch fail-fast
Propagates SDK Breaking Change → bump_min_sdk_version=true	The Release workflow's verify-branch gate re-scans all merged PRs since the last tag and fails loudly if a breaking PR would ship without the bump — automation can't silently under-report

Testing

• YAML validated
• Version-computation logic exercised locally against simulated tag/running-release inputs (tag max 04, in-flight max 07 → correctly computed 08)
• First real-world validation: label a low-risk PR and confirm the dispatch computes the expected next version after merge

Notes

• Requires the PR: Release after merge label to exist on the repo
• Requires secrets.CI_MACHINE_TOKEN (already used by the release workflow itself)

[github-actions]

❌ Linked Issue Needs Team Label

This PR is linked to issue #37383, but that issue has no Team : * label. Every linked issue must be owned by a team for tracking and triage.

How to fix this:

Apply a Team : * label to the linked issue (e.g., Team : Scout, Team : Platform, Team : Falcon, Team : Maintenance). Then push a new commit or edit the PR description to re-run this check.

---

This comment was automatically generated by the issue linking workflow

[claude]

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

---

Code Review

I reviewed the new workflow .github/workflows/issue_release-after-merge.yml.

New Issues

• 🟠 High: .github/workflows/issue_release-after-merge.yml:157,160,163 — Variable case mismatch breaks the PR comment step on every run. The compute step exports the version to GITHUB_ENV as lowercase next_version (line 140: echo "next_version=${NEXT_VERSION}" >> "${GITHUB_ENV}"), but the "Comment on PR with queued release" step references it as uppercase ${NEXT_VERSION} (lines 157, 160, 163). Since that step runs set -euo pipefail and NEXT_VERSION is never defined in its env: block, the first expansion on line 157 hits set -u "unbound variable" and the step aborts. It's masked by continue-on-error: true, so the release still dispatches — but the observability comment (the entire purpose of this step) will never post. Fix either end: write NEXT_VERSION=... to GITHUB_ENV, or reference ${next_version} in the comment step. Fix this →

Notes (non-blocking)

• The core version-computation and dispatch logic is sound: max(tag counter, in-flight counter) + 1 with per-candidate remote re-verification, 10# forcing base-10 on zero-padded counters, the >99 guard, and the single concurrency group serializing concurrent labeled merges all look correct.
• The run-name regex ^Release\ ([0-9]{2}\.[0-9]{2}\.[0-9]{2})-([0-9]{1,2}) correctly matches the Release <version> titles set by cicd_6-release.yml. This couples the two workflows — if that workflow's run-name format ever changes, in-flight detection silently stops working and could hand out a colliding counter. Worth a comment cross-referencing the source of that format (the header comment mentions it, but the dependency is easy to overlook when editing the release workflow).
• ${GITHUB_SERVER_URL} on line 163 is a default Actions env var, so the fallback branch is fine.

Once the casing bug is fixed, this looks good to merge.

_{Note: I can't modify files under .github/workflows/ — GitHub App permissions don't allow workflow changes — so the fix above needs to be applied manually or via the linked Claude Code session.}
• issue-37383-auto-release-after-merge-label