Problem

In order to do automated performance tracking of core, we first need a reliable way of installing core. We have drush site-install, but it can be broken by changes to core. Even if drush responds within days with a fix, there's no simple way to associate a working version of core with a working version of drush.

We also have the install_drupal function (which site-install uses) that takes only a $settings array, formatted in a form-centric way. Code that uses it has to have intimate knowledge of this data structure. Also, it requires more than just that array to function, giving it implicit dependencies.

Solution

The purpose of this patch is to introduce an InstallerInterface which makes each parameter of the installation process explicit. Code that uses this interface should always work, regardless of changes to Drupal itself.

Our requirements for the installation process don't change often, so this interface should be very stable. In the event that we do need to change it, we would create a new version. This provides a reliable mechanism for code to detect what interface should be used, when that code needs to be able to install more than a single version of Drupal.

The provided implementation of this interface acts as a wrapper around the install_drupal function. When we outgrow install_drupal, we simply change the guts of this class and existing code will still work.

Tests

This patch also includes a unit test and an acceptance test, both using PHPUnit. I looked at the existing installer simpletests, and the work necessary to unset and reset the state of the current Drupal request seems far to dangerous for a non-interactive install.

It uses the @runTestsInSeparateProcesses annotation to keep it's state isolated from other tests (since it bootstraps Drupal). There is some awkwardness that comes along with this, but what's there seems to work (see the comments for details).

Since this would be the first non-unit PHPUnit test, I added the "@group slow" annotation, so that it can be excluded when you just want the unit tests to run.

Comments

Status: Needs review » Needs work

The last submitted patch, installer_interface.patch, failed testing.

msonnabaum’s picture

Status: Needs work » Needs review
StatusFileSize
new23.66 KB

Status: Needs review » Needs work

The last submitted patch, installer_interface-2115533-2.patch, failed testing.

msonnabaum’s picture

Issue summary: View changes
Status: Needs work » Needs review
StatusFileSize
new24.28 KB

New version that doesn't try to create a new db, since testbot doesn't have privs to do that.

Status: Needs review » Needs work

The last submitted patch, 4: installer_interface-2115533-4.patch, failed testing.

msonnabaum’s picture

Status: Needs work » Needs review
StatusFileSize
new24.53 KB

A different approach for the cleanup.

Status: Needs review » Needs work

The last submitted patch, 6: installer_interface-2115533-6.patch, failed testing.

msonnabaum’s picture

StatusFileSize
new180.62 KB
msonnabaum’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 8: installer_interface-2115533-8.patch, failed testing.

msonnabaum’s picture

StatusFileSize
new25.24 KB

I'm dumb.

msonnabaum’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 11: installer_interface-2115533-11.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 11: installer_interface-2115533-11.patch, failed testing.

msonnabaum’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 11: installer_interface-2115533-11.patch, failed testing.

msonnabaum’s picture

Status: Needs work » Needs review
StatusFileSize
new25.59 KB

Forgot exception class.

Status: Needs review » Needs work

The last submitted patch, 17: installer_interface-2115533-17.patch, failed testing.

msonnabaum’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 17: installer_interface-2115533-17.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 17: installer_interface-2115533-17.patch, failed testing.

larowlan’s picture

Status: Needs work » Needs review
larowlan’s picture

That test passes locally both via the UI and the cli

Status: Needs review » Needs work

The last submitted patch, 17: installer_interface-2115533-17.patch, failed testing.

andypost’s picture

  1. +++ b/core/tests/Drupal/Tests/Core/Installer/InstallerTest.php
    @@ -0,0 +1,214 @@
    +      'SCRIPT_URL' => '/',
    +      'SCRIPT_URI' => 'http://' . $install_hostname,
    ...
    +      'REQUEST_URI' => '/',
    ...
    +    $request = new Request(array(), array(), array(), array(), array(),array(
    

    the bot executes code in subdir "checkout" so this should not be hard fixed

  2. +++ b/core/tests/autoload.php
    @@ -80,15 +80,3 @@ function drupal_phpunit_register_extension_dirs(Composer\Autoload\ClassLoader $l
    -define('REQUEST_TIME', (int) $_SERVER['REQUEST_TIME']);
    ...
    -setlocale(LC_ALL, 'C');
    ...
    -date_default_timezone_set('UTC');
    

    this could throw some warnings

  3. +++ b/core/lib/Drupal/Core/Installer/Installer.php
    @@ -0,0 +1,384 @@
    +      // When using "localhost", running the acceptance test through the
    +      // simpletest UI, the install fails with:
    +      //
    +      //   "PDO::__construct(): [2002] No such file or directory"
    +      //
    +      // Changing the hostname to to 127.0.0.1 fixes it. However, when running
    +      // the test through the phpunit cli it seems to work fine.
    +      $defaultDbSettings['host'] = '127.0.0.1';
    

    Is it ok to have no localhost? I remember facing this on some debian versions

dmouse’s picture

+1 is it necessary

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

kim.pepper’s picture

tim.plunkett’s picture

Version: 8.6.x-dev » 8.8.x-dev

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.