Repository navigation
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 |
|
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. |
7c12ce6 to
538f9e9
Compare
|
Size Change: 0 B Total Size: 1.26 MB ℹ️ View Unchanged
|
538f9e9 to
f4c6b64
Compare
|
Size Change: 0 B Total Size: 1.26 MB ℹ️ View Unchanged
|
f4c6b64 to
9c87c1a
Compare
Part of #82932.
What?
Removes
composer.json'sconfig.platform.phpvalue ("7.4") and replaces it with an explicitrequire.phpconstraint of">=5.6.20", letting Composer auto-detect the PHP version it is actually running under.Why?
config.platform.phptells Composer to resolve dependencies as though the host were that exact PHP version, no matter what PHP is really in use, and on this branch the hard-coded7.4is now stale:unit-phplegs install on the runner, withshivammathur/setup-phpat the leg's PHP version (5.6,7.0,7.4,8.0,8.2) and thenramsey/composer-install(added by Repairwp/6.1branch Actions: Add a PHP version test matrix #84248). The hard-coded7.4makes every leg resolve as though it ran PHP 7.4, so the5.6and7.0legs get dependencies they cannot run.phpcsjob from Repairwp/6.1branch Actions: Run PHP coding standards on the runner instead of inside wp-env #84250 installs on the runner at PHP 7.4, where the value is redundant.composer installon another PHP version, the hard-coded7.4silently resolves dependencies against the wrong PHP version.So the static value is wrong for most of the CI matrix and a trap outside CI. Removing it and declaring the real floor with
require.phpis whatcomposer.jsonshould have said all along.">=5.6.20"is the correct floor for this branch: it is the minimum PHP version WordPress required from 5.2 until PHP 5.6 support was dropped in 6.3 (WordPress/wordpress-develop@a66e27e), and PHP 5.6 is the lowest version the matrix tests. Verified by simulating dependency resolution for every matrix leg withcomposer update --dry-runagainst realistic patch versions (5.6.40,7.0.33,7.4.33,8.0.30,8.2.26), plus one version below the floor (5.5.38) to confirm the constraint is genuinely enforced.How?
This is a port of the approach taken upstream in commit d2eb077 ("Unit testing: Allow Composer to auto-detect PHP version", WordPress/gutenberg#73358), already present on
wp/6.9and applied towp/6.8throughwp/6.2. Each branch uses its own WordPress release's minimum PHP version as the floor;wp/6.2(#84227) uses the same>=5.6.20.Unlike
wp/6.8–wp/6.2, this branch has no "Override PHP version in composer.json" step inunit-test.yml, so onlycomposer.jsonchanges.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