The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
core/tests/Drupal/Tests/Composer/Plugin/Scaffold/Functional/ComposerHookTest.php is currently failing every build:
1) Drupal\Tests\Composer\Plugin\Scaffold\Functional\ComposerHookTest::testComposerHooks
RuntimeException: Exit code: 2
For additional security you should declare the allow-plugins config with a list of packages names that are allowed to run code. See https://getcomposer.org/allow-plugins
You have until July 2022 to add the setting. Composer will then switch the default behavior to disallow all plugins.
./composer.json has been updated
Running composer update fixtures/scaffold-override-fixture
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
Problem 1
- fixtures/drupal-core-fixture[dev-main, dev-master] require fixtures/drupal-assets-fixture * -> found fixtures/drupal-assets-fixture[dev-master (alias of dev-main), dev-main] but these were not loaded, likely because it conflicts with another require.
- fixtures/drupal-core-fixture dev-master is an alias of fixtures/drupal-core-fixture dev-main and thus requires it to be installed too.
- Root composer.json requires fixtures/drupal-core-fixture * -> satisfiable by fixtures/drupal-core-fixture[dev-master (alias of dev-main), dev-main].
Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
Installation failed, reverting ./composer.json and ./composer.lock to their original content.
Steps to reproduce
Run the test with composer 2.2 locally.
Proposed resolution
Fix the test. It seems that in Composer 2.2 something has changed how dependencies are worked out and our path repos aren't managed quite as well. Given that we're not testing composer's dependency management here - we can fix this by helping composer to install that correct things.
Remaining tasks
N/a
User interface changes
N/a
API changes
N/a
Data model changes
N/a
Release notes snippet
N/a
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 3255836-4.patch | 2.01 KB | alexpott |
Comments
Comment #2
alexpottComment #3
alexpottComment #4
alexpottActually a smaller change works just fine. And the patch will fix 9.x and 10.x at the same time.
Comment #5
alexpottComment #6
clayfreemanComment #7
dwwHit this at #3255756: Add an optional flag to diffAssocRecursive() to allow non-exact comparison. Thanks for opening the issue, and fixing it!
Change looks good, but I think we should wait for bot results before RTBC.
Comment #8
benjifisherI tested the patch in #4 locally, with composer 2.2.1. It seems to work.
I also tested locally without the patch, and got the test failure we are trying to fix.
I will call this +1 for tested, but not reviewed. Why does this change fix the problem? Is this some other change in composer 2.2, besides the one discussed in #3255749: Composer v2.2 prompts to authorize plugins?
Comment #9
benjifisherSorry, I did not read the issue summary before commenting. +1 for RTBC. Let's get this fixed ASAP, and maybe open a follow-up issue to figure out what changed in Composer 2.2 and path repositories.
Comment #10
clayfreeman9.2.x will fail with PHP 8.1, but the failure is unrelated to the change made here. Likely needs a backport from #3224523: [PHP 8.1] Add ReturnTypeWillChange attribute where necessary. RTBC opinion still stands from #6.
Comment #11
spokjeRTBC-ing patch #4 for:
-
D10.0-x:Passed on PHP 8.0 and 8.1-
D9.4-x:Passed on PHP 8.0 and 8.1-
D9.3.x-:Passed on PHP 7.4, 8.0 and 8.1Needs a closer look:
-
D9.2-x:Build successful on PHP 8.1: Since 9.2 never had PHP 8.1 support, I think we can ignore that result.Build successful on PHP 7.3: Looks like a random test failure. Ordered a re-test.
Since tests on issues are failing left, right and centre, and a lot of RTBC patches are already put back to Need Work due to this failure, I'm pro "Add-This-To-9.3.x-And-Upwards" ASAP.
Comment #12
dwwYup, I'm also pro-commit. 😉 Not trying to delay this unnecessarily, I just wanted to see the bot results, first. E.g. I think it's helpful to know this is not yet a clear win for a 9.2.x backport.
But yes, let's fix this ASAP in 10.0.x, 9.4.x and 9.3.x branches. $RTBC++;
Thanks, everyone!
-Derek
Comment #13
spokje9.2.x on PHP 7.3 is now also green.
Comment #14
alexpottCommitted and pushed 638c8bdb93 to 10.0.x and af29dfe9d8 to 9.4.x and 8a3528fecd to 9.3.x. Thanks!
Given I'm committing a patch I wrote and the fact 9.2.x is in security support only I'm going to leave the 9.2.x branch for a release manager to handle.
Comment #18
xjmJust got this back from a job on the private testrunner. Since it will interfere with security testing, I think it's worth a backport to 9.2.x.
The downside is that I don't think it's worth creating a release to just fix this test, so we will have this commit sitting around and never included in a release for 9.2.x unless we have some other hardening or critical backport that we decide to do in a normal patch release, but that's better than security issue tests failing when they shouldn't.
Comment #19
benjifisherThere is also one other RTBC issue that targets 9.2.x: #3217783: Configuration management performance regression - slow config:import. It has a MR, not a patch, so the testbot will leave it at RTBC and fail it every two days.
There are 695 NR issues that target 9.2.x: https://www.drupal.org/project/issues/drupal?status=8&version=all_9.2.*. Someone might review one of them and promote it to RTBC.
Drupal 9.2 still has security coverage. If there is a security update, which is worse: updating from a dev branch that already has this fix or adding this fix to a dev branch that does not have it?
Do we need to update policy? A bug like this, which blocks testing, is already marked Critical. Do we have to say that security-only branches are eligible for bugs like this (or any Critical bug, at the discretion of the release managers)?
Comment #20
xjm@benjifisher There is already a policy. Backports to the security-only branch are always at RM discretion. Certain critical issues will be backported -- testing blockers (like this one), criticals that interfere with the update process, security hardenings for dependency security updates that are not directly exploitable in Drupal, etc. That's why I signed off on the backport above. I was not at my computer so could not cherry-pick it myself at the time.
No issues should be targeting 9.2.x; there should have been a bulk update to 9.3.x for all of them: #3247425: Bulk updates for the 9.3.x release cycle If they are fixed in 9.3.x, they should be closed fixed. If they are not in 9.3.x, they should be moved to 9.3.x. Edit: It looks like the 8.x issues were incorrectly updated to 9.2.x instead of 9.3.x when the bulk updates ran in #3247428: Bulk issue updates for the end of life of Drupal 8.x.y , so we need another bulk update from infra. I've reached out regarding this.
Comment #22
xjmCherry-picked to 9.2.x.