D8: Make testbot check out projects into top-level /modules directory [#2194271]

Since #2171683: Remove all Simpletest overrides and rely on native multi-site functionality instead was committed, all contrib module tests descended from WebTestBase fail, see e.g. https://qa.drupal.org/pifr/test/476768 and https://qa.drupal.org/pifr/test/725203

I think this is because testbot downloads the contrib module to /sites/default, but SimpleTest now runs in a multisite instance at /sites/simpletest, so the module install step in WebTestBase::setUp() cannot find the modules. I guess testbot should now download the contrib module to either /sites/all or /sites/simpletest?

Comments

Comment #1

longwave

he/him

English

CreditAttribution: longwave commented 12 February 2014 at 09:16

#1757536: Move settings.php to /settings directory, fold sites.php into settings.php will further change how multisite works, which may also affect testbot.

Comment #2

sun

German

Karlsruhe

CreditAttribution: sun commented 12 February 2014 at 13:12

Title:	All D8 contrib WebTestBase tests fail	» D8: Tests of all contributed modules fail to run, because modules are not discovered
Parent issue:		» #2171683: Remove all Simpletest overrides and rely on native multi-site functionality instead
Related issues:		+#1757536: Move settings.php to /settings directory, fold sites.php into settings.php

I've created an additional issue for Drupal core, because this is an unfortunate/unexpected consequence of leveraging the multi-site architecture for Simpletest:

#2194445: Web tests of modules in a site-specific directory can no longer be run, because module is not in test site directory

At this point, I'm not sure whether it is a regression that we need to fix. But regardless of whether will be fixed, it would be a good idea to change the testbots to download/checkout extensions into the site-wide directory.

To my knowledge, testbots are using Drush to download/checkout projects.

So for D8, Drush should be adjusted to download/checkout projects into the top-level extension directories; i.e., /profiles, /modules, /themes.

I wonder whether this issue should be moved into the Drush queue? — Or is there a command line flag that allows to control the target "site" directory when downloading/cloning extensions?

Comment #3

Berdir

German

Switzerland

CreditAttribution: Berdir commented 12 February 2014 at 13:17

Testbot is afaik doing (custom?) git based checkouts of modules, not drush.

Drush already puts stuff in /modules in 8.x.

Comment #4

sun

German

Karlsruhe

CreditAttribution: sun commented 12 February 2014 at 14:32

Priority:

Critical

» Normal

#2194445: Web tests of modules in a site-specific directory can no longer be run, because module is not in test site directory has a working patch now, so demoting the priority of this issue.

Comment #5

sun

German

Karlsruhe

CreditAttribution: sun commented 22 February 2014 at 22:16

Title:

D8: Tests of all contributed modules fail to run, because modules are not discovered

» D8: Make testbot check out projects into top-level /modules directory

#2194445: Web tests of modules in a site-specific directory can no longer be run, because module is not in test site directory has been resolved within core now.

However, the upcoming change of #1757536: Move settings.php to /settings directory, fold sites.php into settings.php will most likely break tests for contributed modules + profiles, because they are checked out into e.g. /sites/default/modules (site-specific) instead of /modules (site-wide), and because /sites/default is replaced width the top-level/root directory; i.e., /sites/default will no longer exist.

Re-titling issue accordingly.