Copilot: pre-warm wp-env in the coding agent's setup steps#2473
Conversation
The Copilot coding agent's firewall blocks DNS for hosts not on its allowlist, so `wp-env start` (called from `npm run test-php`) fails when it tries to download WordPress core from wordpress.org. Add `.github/workflows/copilot-setup-steps.yml`, the special workflow Copilot runs in its dev environment before the firewall engages, to pre-fetch everything the agent will need offline later: WordPress core, Composer/npm packages, and the Docker images wp-env uses. The filename and the `copilot-setup-steps` job name are both required exactly for Copilot to pick it up, and the file must be on the default branch to take effect. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
westonruter
added
[Type] Enhancement
The repo's .npmrc sets `ignore-scripts = true` to mitigate supply-chain attacks, which also blocks this project's own `prepare` script from running. So `npm ci` leaves the husky pre-commit hooks (phpstan-diff, PHPCS) uninstalled. Run `npm run prepare` explicitly so the agent's commits get the same hook coverage as a local contributor's. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Pull two additions over from #2352 (Copilot's own attempt at this workflow): - Pin PHP via shivammathur/setup-php so `composer install` runs against a deterministic interpreter across runner image updates. Pinned to 8.2 since that's the WordPress.org-reported most-used PHP version, which matches what most plugin users actually run. - Cache the Composer cache directory across runs. The first session still pays the full packagist download cost, but subsequent setup-step runs restore the cache and `composer install` does much less network work — which both speeds the agent up and reduces firewall surface. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
|
I manually dispatched the workflow and it succeeded: https://github.com/WordPress/performance/actions/runs/26110585007/job/76786447527#step:11:25
|
2 participants
Fixes #2351
Summary
.github/workflows/copilot-setup-steps.yml, the workflow GitHub Copilot's coding agent runs in its dev environment before its network firewall engages.Why
In #2461 the Copilot agent failed running
composer test:pluginsbecause its firewall blocked DNS forwordpress.org— see this comment.wp-env start(whichnpm run test-phptriggers) downloads WordPress core at runtime, and the agent never gets a chance to allowlist the host.The setup-steps workflow is GitHub's intended fix for this: it runs the same install/build/start sequence as
php-test-plugins.ymlwhile the network is still open, so by the time the firewall locks down DNS, everything is already on disk or in the local Docker cache.The filename (
copilot-setup-steps.yml) and the job name (copilot-setup-steps) are required exactly — Copilot won't pick it up otherwise — and the workflow only takes effect once it's on the default branch. See the GitHub docs.Test plan
trunk, trigger a new Copilot coding agent run on a follow-up task that callsnpm run test-phpand confirm thewordpress.orgDNS block no longer appears.push/pull_requestpath filter on this PR will exercise it. Confirm all steps succeed on Actions.🤖 Generated with Claude Code