ci: deploy to dist from the release workflows

[enricobattocchi]

Context

• 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 never started Deploy and Yoast-dist/duplicate-post stopped receiving released code. The dist repository has no 4.7 tag, while 4.6, 4.6-RC1 and 4.6-RC2 are all still there from when tags were pushed by hand.

Summary

This PR can be summarized in the following changelog entry:

• Adds a Deploy to dist job to the Release and Release RC workflows, so a released tag reaches Yoast-dist/duplicate-post again.

Relevant technical choices:

• deploy.yml gains a workflow_call trigger with a ref input and an is-release input, and both release workflows call it after the tag push with secrets: inherit. A reusable workflow can only be called as a job, so the dist deploy runs as a follow-up job after the release job finishes.
• Alternatives considered: push the tag over SSH with the existing YOASTBOT_CI_KEY deploy key, or add a token with write access for this repository. workflow_call needs no extra secret and keeps the dist deploy visible inside the release run.
• A called run has no push event payload, so deploy.yml no longer reads that payload for everything: the ref to build and the release flag come from the inputs (DEPLOY_REF_NAME, IS_RELEASE), and the source commit sha, time and message come from the prepare job, which reads them from the checked-out ref.
• Two side effects on manual Deploy runs: a run against a tag ref now takes the release path instead of creating a dist branch named after the tag, and the dist commit gets a real committer, message, timestamp and commit link instead of empty fields.
• A dry run pushes no tag, so the Deploy to dist job is skipped there. That also means the workflow_call path cannot be rehearsed; the first real exercise is the next RC or release.
• The Release RC job exposes the computed RC version as a job output, because the caller has to pass the tag name to build.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

• Open the three changed workflow files on this branch in the GitHub UI and confirm they render without YAML errors. actionlint 1.7.12 passes on the whole .github/workflows/ directory. No PHP or JavaScript changed, so the PHP and Grunt checks have nothing to check here. composer lint and composer check-branch-cs pass locally; the local composer test run cannot complete because the installed doctrine/instantiator needs PHP 8.4 or newer, so the unit suite is covered by CI on this PR.
• Go to Actions, pick Release RC, run it from this branch with version=99.0 and dry-run=true. Confirm the run is accepted and completes, that Deploy to dist is skipped, and that the dry-run summary lists the dist deploy among the steps it would have taken. A dry run does not exercise the deploy itself; the Actionlint CI job is what checks the call against deploy.yml and its inputs.
• After merge, go to Actions, pick Deploy and run it against the 4.7 tag. Confirm the run syncs to the dist main branch with a commit titled Release 4.7, and that Yoast-dist/duplicate-post ends up with the 4.7 tag it is missing.

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Default Block/Gutenberg/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

QA can test this PR by following these steps:

• This PR only changes release plumbing; there is nothing to test in the plugin. The Release RC run that produces the RC is itself the test: confirm it ends with a Deploy to dist job that pushes the RC tag to Yoast-dist/duplicate-post.

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

• No plugin code. The Deploy workflow is shared with pushes to trunk, release/*, hotfix/* and feature/*, so the first push to one of those after merge is worth a look: it should still sync to a same-named dist branch with a Syncing branch ... commit.

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Documentation

• I have written documentation for this change. For example, comments in the Relevant technical choices, comments in the code, documentation on Confluence / shared Google Drive / Yoast developer portal, or other.

The header comment in release.yml claimed the tag push triggers deploy.yml. It is corrected, and both release workflow headers now describe the dist deploy and why the tag push cannot start it.

Quality assurance

• I have tested this code to the best of my abilities
• I have added unittests to verify the code works as intended

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label and noted the work hours.

Fixes #542

[coveralls-official]

Coverage Report for CI Build 34480703200

Warning

No base build found for commit 5f6ac71 on trunk.
Coverage changes can't be calculated without a base build.
If a base build is processing, this comment will update automatically when it completes.

Coverage: 62.83%

Details

• Patch coverage: No coverable lines changed in this PR.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

Requires a base build to compare against. How to fix this →

---

Coverage Stats

Relevant Lines:	2728
Covered Lines:	1714
Line Coverage:	62.83%
Coverage Strength:	9.29 hits per line

---

💛 - Coveralls