Release workflows do not trigger the dist deploy
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 53
- Forks
- 38
- Avg merge
- 4d 8h
- Merged PRs (30d)
- 1
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with deploy.yml, release.yml, and the Release and Release RC workflows, tracing the current push-event values and tag-push steps. Update the workflow inputs and headers so both release paths invoke Deploy after tagging; done means normal releases deploy the tag to Yoast-dist/duplicate-post while dry runs skip deployment.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- ci-cd, release
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100