Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem
- Various patches in the queue are or will fail on re-test if they happen to use the Testing profile and if they still happen to assume that Node module gets installed.
Goal
- Decrease havoc caused by #375397: Make Node module optional. Testing philosophies around Node module will only need to change after #1373142: Use the Testing profile. Speed up testbot by 50%.
Comment | File | Size | Author |
---|---|---|---|
#7 | drupal8.testing-node.7.patch | 1.79 KB | sun |
#4 | drupal8.testing-node.4.patch | 950 bytes | sun |
drupal8.testing-node.0.patch | 343 bytes | sun | |
Comments
Comment #1
aspilicious CreditAttribution: aspilicious commentedOk that has to be done :)
Comment #2
sunFWIW, I manually tested and can confirm that this change resolves fatal errors and makes such patches pass again; e.g.:
#1376166-28: Custom logo and favicon functionality inanely tries to support absolute local file paths
Comment #3
sunHold on, we also need the 'access content' permissions.
Comment #4
sunAttached patch additionally restores/reverts the testing.install change of the Node-optional patch:
http://drupalcode.org/project/drupal.git/blobdiff/25043d962b6d2bf755d7a1...
Comment #5
sunThe permissions are required, because tests, which assume that Node module is installed, also assume that the built-in anonymous and authenticated user roles can 'access content'. Merely installing Node module does not grant the permissions.
The missing permissions also explain the huge amount of test failures in the patch with ".node." suffix in http://drupal.org/node/1373142#comment-5443554 - which should have passed just like the one before.
Comment #7
sunThe reason for why that test fails is that the test already uses the Testing profile, but does not account for (non-required) modules being already installed by the installation profile.
Therefore, the test worked, since the Testing profile did not install any additional modules in the past.
Attached patch makes the test account for already pre-installed modules by the installation profile, so that these are not attempted to be enabled. The final module disable and uninstall assertions are still executed for them though (since they are optional).
Thus, this patch should come back green and be RTBC.
Comment #8
sunAlright, so the patch passed tests.
However, I'm no longer sure whether we need to do this, because we're in a weird situation now:
Kind of a chicken-and-egg situation.
Comment #9
sunGrace period is over.