Skip running irrelevant actions on forks#3473
Conversation
Add github.repository == 'WordPress/wordpress-playground' guard to deploy, publish, and refresh workflows so they no longer create skipped runs in the Actions UI of forks. CI is intentionally untouched so tests still run on forks. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
This PR reduces GitHub Actions usage on forks by gating deploy/publish/refresh (and related) workflows so they only run in the upstream WordPress/wordpress-playground repository.
Changes:
- Added
github.repository == 'WordPress/wordpress-playground'job-level guards across multiple workflows. - Updated workflow comments to reflect the new “only run on upstream repo” behavior.
- Wrapped/adjusted some
if:expressions to keep existing logic intact with the new guard.
Reviewed changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| .github/workflows/update-changelog.yml | Adds upstream-repo guard to the changelog update job. |
| .github/workflows/refresh-wordpress-nightly.yml | Adds upstream-repo guard to nightly refresh job. |
| .github/workflows/refresh-wordpress-major-and-beta.yml | Adds upstream-repo guard to major/beta refresh job. |
| .github/workflows/refresh-sqlite-integration.yml | Adds upstream-repo guard to sqlite integration refresh job. |
| .github/workflows/publish-self-hosted-package-release.yml | Adds upstream-repo guard to self-hosted release publishing job. |
| .github/workflows/publish-npm-packages.yml | Adds upstream-repo guard to npm publish workflow. |
| .github/workflows/publish-github-release.yml | Adds upstream-repo guard and groups conditions for GitHub release creation. |
| .github/workflows/publish-devtools-extension.yml | Adds upstream-repo guard to devtools extension publish job. |
| .github/workflows/deploy-website.yml | Adds upstream-repo guard to website deploy job. |
| .github/workflows/deploy-my-wordpress-net.yml | Adds upstream-repo guard to my.wordpress.net deploy job. |
| .github/workflows/deploy-cors-proxy.yml | Adds upstream-repo guard to CORS proxy deploy job. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if: > | ||
| github.repository == 'WordPress/wordpress-playground' && | ||
| github.ref == 'refs/heads/trunk' && ( |
There was a problem hiding this comment.
The PR description says the guard is added to deploy/publish/refresh workflows, but this PR also updates update-changelog.yml. Either update the PR description to include this workflow or drop the change here to keep scope aligned.
| # Only run this workflow from the trunk branch and when it's triggered by another workflow OR a Playground maintainer | ||
| # Only run this workflow on the playground repo, from the trunk branch, and when triggered by another workflow OR a Playground maintainer | ||
| if: > | ||
| github.repository == 'WordPress/wordpress-playground' && |
There was a problem hiding this comment.
The literal repository string WordPress/wordpress-playground is duplicated across many workflows in this PR, which makes future renames/error fixes repetitive and easier to miss. Consider centralizing it via a repo/org variable (e.g., vars.OFFICIAL_REPO) and comparing against that, or using a less brittle predicate like github.repository_owner == 'WordPress' combined with the repo name.
| github.repository == 'WordPress/wordpress-playground' && | |
| github.repository_owner == 'WordPress' && | |
| github.event.repository.name == 'wordpress-playground' && |
|
@dd32 thank you! AFAIR Telex had a separate Playground deployment managed from a fork of this repo, that would be affected by this PR. What would be an easy way for the repo to opt-in or opt-out of these workflows? CC @brandonpayton |
|
@adamziel Yes, if Telex or others have a fork of the repo that is expected to run these actions then that would affect them. Personally I'd say it shouldn't be assumed that a fork of a repo should run actions on trunk, only on custom branches / PRs... I was planning to just delete my fork (or remove it's auto-sync-with-upstream) to avoid the issues I had.. |
Motivation for the change, related issues
While looking at my actions usage on my personal github account, I noticed that Playground is using up a lot of actions resources on my fork, dd32/wordpress-playground.
Upon looking into it, i saw that a bunch of jobs are running that doesn't appear to be needed.
Implementation details
Add github.repository == 'WordPress/wordpress-playground' guard to deploy, publish, and refresh workflows so they no longer attempt to run on forks.
Testing Instructions (or ideally a Blueprint)