What is the goal of this issue?
Make the Deploy workflow run for every release, so Yoast-dist/duplicate-post keeps receiving the released code and tags.
What needs to be done to achieve the goal?
Release and Release RC push their tag with the built-in Actions token. GitHub raises no events for pushes made with that token, so the tag push does not start Deploy and nothing reaches the dist repository. The dist repo has no 4.7 tag, while 4.6, 4.6-RC1 and 4.6-RC2 are all present from the era when tags were pushed by hand.
Give deploy.yml a workflow_call trigger and call it from both release workflows after the tag push.
Does the issue still need UX or research?
No.
If available: what are the tips for fixing the problem or possible solutions?
Alternatives considered: push the tag over SSH with the existing YOASTBOT_CI_KEY deploy key, or add a personal access token with write access for this repository. Both start Deploy through a real event, but workflow_call needs no extra secret and shows the dist deploy as part of the release run.
deploy.yml reads the ref name, the release flag and the source commit metadata from the push event payload, which a called run does not have. Those values need to come from inputs and from the checked-out ref instead.
What is the expected result/behavior?
A Release or Release RC run ends with a Deploy to dist job that builds the tag and pushes the artifact and the tag to Yoast-dist/duplicate-post. A dry run skips it.
Should documentation be added or updated for this change? and if so, where?
The header comment in release.yml claims the tag push triggers deploy.yml. Correct it, and describe the dist deploy in both release workflow headers.
What is the goal of this issue?
Make the
Deployworkflow run for every release, soYoast-dist/duplicate-postkeeps receiving the released code and tags.What needs to be done to achieve the goal?
ReleaseandRelease RCpush their tag with the built-in Actions token. GitHub raises no events for pushes made with that token, so the tag push does not startDeployand nothing reaches the dist repository. The dist repo has no4.7tag, while4.6,4.6-RC1and4.6-RC2are all present from the era when tags were pushed by hand.Give
deploy.ymlaworkflow_calltrigger and call it from both release workflows after the tag push.Does the issue still need UX or research?
No.
If available: what are the tips for fixing the problem or possible solutions?
Alternatives considered: push the tag over SSH with the existing
YOASTBOT_CI_KEYdeploy key, or add a personal access token with write access for this repository. Both startDeploythrough a real event, butworkflow_callneeds no extra secret and shows the dist deploy as part of the release run.deploy.ymlreads the ref name, the release flag and the source commit metadata from thepushevent payload, which a called run does not have. Those values need to come from inputs and from the checked-out ref instead.What is the expected result/behavior?
A
ReleaseorRelease RCrun ends with aDeploy to distjob that builds the tag and pushes the artifact and the tag toYoast-dist/duplicate-post. A dry run skips it.Should documentation be added or updated for this change? and if so, where?
The header comment in
release.ymlclaims the tag push triggersdeploy.yml. Correct it, and describe the dist deploy in both release workflow headers.