Make WordPress Core

Opened 8 months ago

Last modified 6 months ago

#59110 new defect (bug)

Make the database container in the local Docker environment more generic

Reported by: desrosj's profile desrosj Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords: has-patch
Focuses: Cc:

Description

Currently, mysql is hard coded in several locations within the docker-compose.yml file. Although changing database types works interchangeably for the most part (Core also supports MariaDB), it is confusing to have a container named mysql that runs MariaDB.

For previous MariaDB versions, the mysql command is symlinked to the mariadb one. However, in MariaDB 11.0 that symlink is removed and causes failures. Making this container more generic will help spot commands still using mysql, and other potential issues.

Change History (9)

This ticket was mentioned in PR #5014 on WordPress/wordpress-develop by @desrosj.


8 months ago
#1

  • Keywords has-patch added

#2 @desrosj
8 months ago

Related: #30462.

@johnbillion commented on PR #5014:


8 months ago
#3

Can you add some instructions on testing this locally? I presume it needs a stop, install, and start again so the container is restarted with the correct name and the wp-config.php file is updated with the correct host name.

@desrosj commented on PR #5014:


8 months ago
#4

Can you add some instructions on testing this locally? I presume it needs a stop, install, and start again so the container is restarted with the correct name and the wp-config.php file is updated with the correct host name.

Sure!

To test this, you'll need to perform the following on a pre-existing setup:

  • npm run env:pull
  • npm run env:restart
  • npm run env:install

This will test the new compose file with MySQL (the default). To then test with MariaDB, run the same commands as above but run the following two commands first (or update the .env file to reflect these instead):

  • export LOCAL_DB_TYPE=mariadb
  • export LOCAL_DB_VERSION=11.0 (or any other valid MariaDB version).

Unfortunately, after this change, I believe that any local setup using the current configuration would see their database reset. I'm not sure how to avoid that with this change.

@johnbillion commented on PR #5014:


8 months ago
#5

We could avoid the data loss by retaining the mysql volume name, but that would somewhat reduce the effect of the ticket.

@desrosj commented on PR #5014:


8 months ago
#6

We could post a brief note on Making WordPress Core detailing this. Another possible path we could take is to export the database when running npm run env:stop. However, it would need to be run prior to the new compose file being put in place locally. So it would need to be a changeset preceding any including this PR.

@johnbillion commented on PR #5014:


8 months ago
#7

Perhaps retaining the mysql volume is ok?

@desrosj commented on PR #5014:


8 months ago
#8

I don't have strong opinions against that, but it doesn't fully resolve the potential confusion the ticket aims to address.

What if we were to include both the new one in this PR and mysql for a period of time? Then the volume would still be there, but by default it would switch to the new one. Someone could use a .docker-compose.override.yml file to switch back to export their data. We could include that in the post.

#9 @desrosj
6 months ago

  • Milestone changed from 6.4 to Future Release
Note: See TracTickets for help on using tickets.