Problem
cicd_comp_changelog-site-publish-phase.yml declares workflow_call: only. When the release pipeline skips it — which happens whenever an upstream job fails or is cancelled, since the job is gated on needs: [..., release-notes] + success() — there is no way to publish that release's changelog from CI.
The only remaining path is running the publisher locally, which requires an operator to know and obtain three values that otherwise never leave GitHub:
DOTCMS_DEVSITE_URL (repo variable)DOTCMS_DEVSITE_RELEASENOTES_TOKEN (repo secret, Keeper)DOTCMS_DEVSITE_RELEASENOTES_ACCOUNT (repo variable)
This came up on 26.08.19: four release attempts, three of which shipped Docker images with no changelog at all, and the fourth published a changelog covering 1 of 19 commits. Recovering it needed a local checkout plus credentials from Keeper.
Related: the phase's own comments describe --force as "a manual operator re-run only", but no manual re-run path exists — the flag is unreachable from CI.
Proposal
Add cicd_manual_changelog-site-publish.yml, a workflow_dispatch wrapper around the existing reusable phase — the same pattern cicd_ai-release-notes-backfill.yml already uses for the release-notes phase. Credentials stay in repo vars/secrets; an operator supplies only the release tag, from the Actions UI or gh workflow run.
The wrapper derives what the pipeline would have passed:
release_version from the tagdocker_tags — the sha-tagged image, looked up from Docker Hub's public API, so a manual entry matches a pipeline-written onereleased_date from the release's own publishedAt, so backfilling an older release does not stamp today's date
Two small additions to the phase workflow, both defaulting to current behavior so the release pipeline is unchanged:
force (boolean, default false) — threads --force through for the documented overridereleased_date (string, default empty) — falls back to $(date -u +%F) exactly as today
Out of scope
The auto-detect bug that caused the wrong 26.08.19-04 changelog (findPreviousTag() picking the immediately-preceding tag) is a separate issue.
Problem
cicd_comp_changelog-site-publish-phase.ymldeclaresworkflow_call:only. When the release pipeline skips it — which happens whenever an upstream job fails or is cancelled, since the job is gated onneeds: [..., release-notes]+success()— there is no way to publish that release's changelog from CI.The only remaining path is running the publisher locally, which requires an operator to know and obtain three values that otherwise never leave GitHub:
DOTCMS_DEVSITE_URL(repo variable)DOTCMS_DEVSITE_RELEASENOTES_TOKEN(repo secret, Keeper)DOTCMS_DEVSITE_RELEASENOTES_ACCOUNT(repo variable)This came up on 26.08.19: four release attempts, three of which shipped Docker images with no changelog at all, and the fourth published a changelog covering 1 of 19 commits. Recovering it needed a local checkout plus credentials from Keeper.
Related: the phase's own comments describe
--forceas "a manual operator re-run only", but no manual re-run path exists — the flag is unreachable from CI.Proposal
Add
cicd_manual_changelog-site-publish.yml, aworkflow_dispatchwrapper around the existing reusable phase — the same patterncicd_ai-release-notes-backfill.ymlalready uses for the release-notes phase. Credentials stay in repo vars/secrets; an operator supplies only the release tag, from the Actions UI orgh workflow run.The wrapper derives what the pipeline would have passed:
release_versionfrom the tagdocker_tags— the sha-tagged image, looked up from Docker Hub's public API, so a manual entry matches a pipeline-written onereleased_datefrom the release's ownpublishedAt, so backfilling an older release does not stamp today's dateTwo small additions to the phase workflow, both defaulting to current behavior so the release pipeline is unchanged:
force(boolean, default false) — threads--forcethrough for the documented overridereleased_date(string, default empty) — falls back to$(date -u +%F)exactly as todayOut of scope
The auto-detect bug that caused the wrong 26.08.19-04 changelog (
findPreviousTag()picking the immediately-preceding tag) is a separate issue.