InstallerTestBase tests can not be run locally

Had the exact same problem, thanks @tstoeckler for the pointer.

+++ b/core/modules/simpletest/src/InstallerTestBase.php
@@ -84,11 +84,11 @@ protected function setUp() {
-    // If any $settings are defined for this test, copy and prepare an actual
-    // settings.php, so as to resemble a regular installation.
+    copy(DRUPAL_ROOT . '/sites/default/default.settings.php', DRUPAL_ROOT . '/' . $this->siteDirectory . '/settings.php');
     if (!empty($this->settings)) {
-      copy(DRUPAL_ROOT . '/sites/default/default.settings.php', DRUPAL_ROOT . '/' . $this->siteDirectory . '/settings.php');

InstallerTestBase only provisions a settings.php upfront, if the test defines $settings that should be written upfront.

There are two possible installer code paths here:

A) Install from clean slate, no settings.php (only a site directory)

B) Install with prepared settings.php that primes some settings prior to hitting the installer.

This patch changes all installer tests to always run through B), because the code unconditionally copies settings.php ahead of time.

Most likely caused by this issue.

I assume we're missing a logger in the minimal container that's set up by InstallerTestBase.

I'm not able to reproduce this issue, neither when running DistributionProfileTest via CLI nor through the UI.

In didn't worked for me on the InstallerTest, installed in a subdir (if this matters at all).

chown wwwrun default.settings.php and sudo -u wwwrun php run-tests.sh works.

Thanks, that's a useful hint, @olli.

So I suspect the problematic flow is the following — only applies to installer tests that do NOT write out a settings.php upfront:

1. [test-runner] Test hits http://localhost/install.php via internal browser.
2. [web-server] Installer writes settings.php.
3. [web-server] Installer chmod's settings.php to be read-only.
4. ...Test proceeds...
5. [test-runner] Attempts to tear down + clean-up/delete test site environment, but settings.php is read-only → Error.

Hm. I think I ran into this problem space a while ago already. Played with the slightly crazy idea of adding a test-only "self-destruct" route in #2194089-11: file_unmanaged_delete_recursive() randomly fails

Rerolled #1, but it didnt work for me. #7 permissions didnt work for me neither.
Needs review just for the testbot.

Setting owner for both the default.settings.php and default.services.yml files works for me. I guess these lines in install_check_requirements might be related:

        if (fileowner($default_file) === fileowner($file)) {
...
        }
        // If $file and $default_file have different owners, this probably means
        // the server is set up "securely" (with the webserver running as its
        // own user, distinct from the user who owns all the Drupal PHP files),
        // although with either a group or world writable sites directory.
        // Keeping $file owned by the webserver would therefore introduce a
        // security risk. It would also cause a usability problem, since site
        // owners who do not have root access to the file system would be unable
        // to edit their settings file later on. We therefore must delete the
        // file we just created and force the administrator to log on to the
        // server and create it manually.
        else {
          $deleted = @drupal_unlink($file);

#14 didn't work for me :/

sudo -uwww-data php ./core/scripts/run-tests.sh --verbose  --color --url http://d8.local/ --class "Drupal\system\Tests\Installer\InstallerLanguagePageTest"

#14 DID WORK for me. The problem I was having is that php5-sqlite was not installed on my system, so the database type radio couldn't be set as it was disabled.

Requiring sqlite for running tests is another story, so marking as RTBC as this is a really annoying bug which looks like is not possible to reproduce in a test.

Sqlite issue: #2355523: InstallerTestBase tests should not require sqlite to be installed

Looks like the change is minimal (just a condition addition and if statement placement change). +1 to get this in :)

This also affects the new Docker based TestBots where most Installer group tests are failing. With patch from #14 all Installer tests do pass now, for both, MySQL and PostgreSQL environments. Great!

Committed/pushed to 8.0.x quickly to unblock things.