Yoast / Yoast/duplicate-post

Release workflows do not trigger the dist deploy

Open
#542 0 comments 0 reactions 0 assignees View on GitHub

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.