Problem/Motivation

Follow-up of #3089900: Drupal 8.8/8.9/9.0 update test coverage

It's very painful to write update tests for modules that aren't enabled in the filled dump by default.

Proposed resolution

That issue on purpose kept the filled dump as similar as possible but as discussed in Slack, we should enable new stable modules there as well and also add some content (medias, layouts, drafts..?)

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

Berdir created an issue. See original summary.

berdir’s picture

Version: 9.0.x-dev » 8.9.x-dev
Status: Active » Needs review
StatusFileSize
new3 KB
new719.61 KB

Starting this, here's what I did:

git checkout 8.8.x
php ./core/scripts/db-tools.php import --database d8_import /core/modules/system/tests/fixtures/update/drupal-8.8.0.filled.standard.php.gz
git checkout 8.8.0

* change db connection to point to d8_import
* login with drupal/drupal
* go to admin/modules

Enabled the following modules:

Core:
* BigPipe
* Content Moderation
* Inline Form Errors
* Internal Dynamic Page Cache
* Layout Builder
* Layout Discovery
* Media
* Media Library
* Settings Tray
* Workflows

Experimental:
* Help Topics
* Workspaces

Field Types:
* Datetime Range

Web Services:
* JSON:API

I also considered to enable "Migrate Drupal UI", but that actually failed with an error on install, so I restarted the whole thing and didn't include that.

=> 14 modules have been enabled: BigPipe, Content Moderation, Datetime Range, Internal Dynamic Page Cache, Help Topics, Inline Form Errors, JSON:API, Layout Builder, Layout Discovery, Media, Media Library, Settings Tray, Workflows, Workspaces.

* I created one image media druplicon.png and one document README.txt.

* I switched to the Stage workspace, edited "Test page"

* I enabled Layout Builder for Article display, including per per-content customization. I configured the layout a bit and also customized the Test Article.

* The dumped:

php ./core/scripts/db-tools.php dump-database-d8-mysql > core/modules/system/tests/fixtures/update/drupal-8.8.0.filled_all_modules.standard.php

non-gz increased from 5M to 7M, gz is 714k

I then added a test for this that asserts some of the changes that I did. Did extend from \Drupal\FunctionalTests\Update\UpdatePathTestBase and not \Drupal\FunctionalTests\Update\UpdatePathTestBaseTest as I didn't see the point of doing all those generic checks again.

longwave’s picture

Could we use Umami as the source of the filled database dump? Or at least script the creation, so we can repeat this again easily in the future?

berdir’s picture

umami is by design not updateable, so I don't think that makes sense?

Not much to script here IMHO, the import/export is already scripted and the parts between are going to be different each time? You can also import my dump, make further changes and export again, don't need to repeat my steps unless for some reason my dump is completely wrong.

I did enable the modules and made changes on purpose manually in the UI to make it as real as possible (instead of using drush en)

amateescu’s picture

I think this is a very good idea! It certainly makes it easier to test the upgrade path for modules that are not enabled by default in the Standard profile.

  1. +++ b/core/modules/system/tests/src/Functional/UpdateSystem/UpdatePathTestBaseFilledAllModulesTest.php
    @@ -0,0 +1,93 @@
    + * Runs UpdatePathTestBaseTest with a filled dump including new modules.
    

    This comment contradicts the last paragraph from #2 :)

  2. +++ b/core/modules/system/tests/src/Functional/UpdateSystem/UpdatePathTestBaseFilledAllModulesTest.php
    @@ -0,0 +1,93 @@
    +    $assert_session->pageTextContains('druplicon.png');
    +
    +
    +
    +
    +  }
    

    Extra empty lines that should be removed.

jibran’s picture

Can we please also add a script or document how to rebuild filled DB? Sometimes recreation of the DB dump file is easier than manually adding the changes introduced. Or instead of creating filled DB we can standardize on using bare one and running the content creation script on top of it?

In DER, I have the following scripts update_test_8201.php and update_rev_test_8201.php to re-create the DB dump.

gábor hojtsy’s picture

Tagging as beta requirement per @xjm in #3108254-17: [META] Drupal 8-9 upgrade path clean-up.

catch’s picture

Component: simpletest.module » database update system
xjm’s picture

Issue tags: +beta target
catch’s picture

Priority: Normal » Major

This seems major given how much work it saves for future upgrade path testing.

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.

tim.plunkett’s picture

Status: Needs review » Needs work

I spent a good chunk of time trying to follow @jibran's very good suggestion to make this repeatable.
However, I can't get it working as I'd like to, and I don't want to hold up this issue anymore.
I'll open a follow-up to further explore #6, but marking this needs work for #5 and to continue the efforts of #4.

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.

xjm’s picture

Version: 9.2.x-dev » 9.0.x-dev
Issue tags: -Drupal 9.0.0-beta1 requirement, -beta target

Cleaning up leftover beta targets from 9.0.x.

As test improvement, this is eligible for the bugfix branch, I'd think.

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

Drupal 9.0.10 was released on December 3, 2020 and is the final full bugfix release for the Drupal 9.0.x series. Drupal 9.0.x will not receive any further development aside from security fixes. Sites should update to Drupal 9.1.0 to continue receiving regular bugfixes.

Drupal-9-only bug reports should be targeted for the 9.1.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.2.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

tim.plunkett’s picture

#3194562: Add database dumps for 9.0.0 added bare and filled dumps for 9.0.0, but did not install new stable modules or provide content for them. So this issue is still relevant.

andypost’s picture

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

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.