Repository navigation
Repair wp/5.5 branch Actions: Let the current Composer release install this branch's dependencies - #85004
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
wp/5.5 branch Actions: Run PHP coding standards on the runner instead of inside wp-env
#85003
|
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. |
desrosj
changed the title
wp/5.5 branch Actions: Allow Composer pluginswp/5.5 branch Actions: Let the current Composer release install this branch's dependencies
Part of #82938.
What?
Declares
config.allow-pluginsincomposer.jsonforcomposer/installersanddealerdirect/phpcodesniffer-composer-installer. It also pinswp-env'scomposerservice to thecomposer:2image instead of the floatingcomposerimage, with apackages/env/CHANGELOG.mdentry.Why?
Composer 2.2+ requires plugins to be allowed explicitly. Without the block,
composer installfails under current Composer (exit1):--no-pluginsisn't a substitute:dealerdirect/phpcodesniffer-composer-installeris what registers the PHPCS standards, and without itphpcsfails withReferenced sniff "PHPCompatibility" does not exist.The
composerimage is pinned tocomposer:2, not to an exact release. Composer's security fixes and its advisory policy (#85005, directly above) only arrive with new releases.composer:2still gets every Composer 2 release, including security fixes, but a future Composer 3 can't change how this branch installs its dependencies until someone updates the tag. The PHP version inside the image still follows the tag (PHP 8.5 today); that doesn't change which packages get installed, becausecomposer.lockdecides that. Nothing in that container needs an older PHP: its only job iscomposer install, which works on the current image (Composer 2.10.3, PHP 8.5.10). PHP_CodeSniffer, which can't run on current PHP, runs on the runner at PHP 7.4 after #85003 (directly below).Testing
In the
composerimage (Composer 2.10.3, PHP 8.5.10), against this branch'scomposer.lock:composer installexits0withallow-pluginsandvendor/bin/phpcsexists afterwards; without it, the install exits1.configisn't part of the lock's content hash, so the lock doesn't change.composer:2is currently the same image as the floatingcomposerimage, so these results apply to it.Use of AI Tools
This PR was created by Claude Code under my supervision. All code should be treated as AI-produced and not yet reviewed by a human until this PR is marked Ready for Review.
🤖 Generated with Claude Code