Needs work
Project:
Drupal core
Version:
main
Component:
database update system
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
19 Nov 2019 at 11:41 UTC
Updated:
30 Mar 2021 at 10:13 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
berdirStarting this, here's what I did:
* 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:
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.
Comment #3
longwaveCould 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?
Comment #4
berdirumami 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)
Comment #5
amateescu commentedI 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.
This comment contradicts the last paragraph from #2 :)
Extra empty lines that should be removed.
Comment #6
jibranCan 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.
Comment #7
gábor hojtsyTagging as beta requirement per @xjm in #3108254-17: [META] Drupal 8-9 upgrade path clean-up.
Comment #8
catchComment #9
xjmComment #10
catchThis seems major given how much work it saves for future upgrade path testing.
Comment #12
tim.plunkettI 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.
Comment #14
xjmCleaning up leftover beta targets from 9.0.x.
As test improvement, this is eligible for the bugfix branch, I'd think.
Comment #16
tim.plunkett#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.
Comment #17
andypost