This test plan covers most of the features and bug in v1.13. You can use v1.13.0-rc1 to test, preferably from homebrew edge repo or Chocolatey. Please report back in this issue (or create new issues if more appropriate). Thanks!

import-db changes:
- Verify that ddev import-db --no-drop will add a new table to database, see #1961. Start with an existing database that has tables and content, and import stdintable.sql. with —no-drop. All the original tables should still be there, and now there should be stdintable as well.
- Verify that ddev import-db -f stdintable.sql results in just a single table in the database. (use ddev mysql and SHOW TABLES;
- ddev delete <project> -O to delete and then ddev import-db -f stdintable.sql --target-db=newdb. Now there should be no tables in the "db" database, and the one table in the "newdb" database.
- ddev import-db <projectname> -f stdintable.sql should successfully import that stdintable into the named project.
export-db changes:
- ddev export-db <project> --gzip=false -f junk.sql should result in an sql dump from the named project that is not gzipped.
Test global_config.yaml accidental overwrite and reset of instrumentation perms:
- See #1882
- The repeated problem was that global_config.yaml was overwritten with defaults when a WordPress project was started. It probably won't manifest that way any more, but still needs retest.
- Verify that changing ddev version does the right thing once and that the contents of the global_config.yaml stay there.
Custom Container Build (#2042):
- Add webimage_extra_packages to one project. Verify that a -built container containing the name of that project exists
- Start another project. ddev ssh and use dpkg -l to verify that the second project does not have the package added above.
- Add a file (TESTME.txt maybe) to .ddev/web-build and then add it to container with custom Dockerfile that says ADD TESTME.txt / - after ddev start you should find that ddev exec ls -l /TESTME.txt shows the file in the root of the container.
disable_settings_management:
- On each Drupal 7, Drupal 8, TYPO3
- Set disable_settings_management: true
- Remove settings files (or preferably start from scratch from ddev config all the way through
- Verify that the extra settings files and settings manipulation that ddev normally does (settings.php, setting.ddev.php, AdditionalConfiguration.php, etc) do not get created.
backdrop drush extensions: Verify that the backdrop drush extensions are 1.2.0. I'm not sure how to do this yet.
Drush version: Verify that drush is 8.3.2. On a Drupal 7 project (or any non-drupal8) ddev exec drush --version (or anywhere, ddev exec -d /tmp drush8 --version
restore-snapshot in autocomplete. You should be able to ddev rest<tab> and see restore-snapshot as long as autocompletion is working correctly for homebrew. It should be included in the ddev file in brew's bash-completion.d
Drupal 8 config_sync_directory needs to function differently for Drupal 8.8 and 8.9 (and 9.x). Do a ddev config and review settings.ddev.php. Then verify correct behavior on Drupal 8.8 and 8.9 - watch for warnings.
xdebug stopping too many places: See #1996 for recreation script and instructions. On PHP 7.0 the bug still exists because of how it was built on upstream, but all other PHP versions should work OK.
Magento (1): Use the magento quickstart to install Magento. Get the sample data. Make sure it works
*Magento 2: Use the magento 2 quickstart to install Magento 2. Get sample data. make sure it works.
IS_DDEV_PROJECT: Make sure it works as expected. Simple technique is to set up a Drupal 8 project and then try hosting that project in Apache on host. It should work fine if settings.php points to the right thing, should not be broken by included settings.ddev.php. Try on TYPO3 and Drupal 7 as well if possible.
Drupal 8 drush.yml should be in <approot>/drush, not sites/all/drush
Quickstarts: Verify all documented quickstarts (on "latest" (magento and magento2 would have been done above)
Create .ddev/.gitignore on ddev start. This file gitignores itself, so teams that have projects checked in want to make sure it gets re-populated. Delete .ddev/.gitignore and then ddev start, preferably with a project under git control. After ddev start git status should show everything OK.
Subdirectories in .ddev/commands/* should not show up as commands. mkdir .ddev/commands/web/junk and you should not have a ddev junk command listed.
ddev notarized on macOS: Use the techniques at signing_tools to verify that the ddev binary distributed with homebrew on macOS Catalina passes all tests. Try the tarball download and install as well.
Make sure ddev exec enable_xdebug works on apache-cgi (and xdebug works)
Make sure utf8mb4 client collation works per #2006
Pantheon integration: Test pantheon integration per docs (latest), do all the things.
PHP7.3: Make sure default PHP version on new project is PHP7.3

Most things tested out fine, A couple of cleanup things to do.

Working with v1.13.0-rc1 on Windows 10 Home with WSL2 (Linux Ubuntu 18.04)

import-db changes:
- ✅ Verify that ddev import-db --no-drop will add a new table to database: Tested with a single .sql that added a "newusers" table. And it did, rest was fine.
- ✅ Verify that ddev import-db -f stdintable.sql results in just a single table: Worked correctly
- ✅ Empty database with import to —target-db results in new populated db.
- ✅ import-db using projectname as first arg works along with everything else
export-db changes:
- ✅ ddev export-db <project> --gzip=false -f junk.sql should result in an sql dump from the named project that is not gzipped: This one works fine.
- 👎 ddev import-db -d newdb and then try to dump it with ddev export-db -d newdb. Unfortunately this one reports "Wrote database dump from d8composer database 'db' to stdout in gzip format" - it didn't export the named database. (Fixed and with improved test in https://github.com/drud/ddev/pull/2058)
Test global_config.yaml accidental overwrite and reset of instrumentation perms:
- ✅ I wasn't able to recreate the corruption/removal of global_config.yaml. I did step through initialization of the command structure and it does initialize during a.go, which seems soon enough.
- ✅ Verify that changing ddev version does the right thing once and that the contents of the global_config.yaml stay there: This worked fine for me. I manually changed last version, did start, it asked. Started again, didn't ask.
Custom Container Build (#2042):
- ✅ Add webimage_extra_packages to one project. Verify that a -built container containing the name of that project exists: Worked. Also docker images showed built images container project name for each project.
- ✅ Start another project. ddev ssh and use dpkg -l to verify that the second project does not have the package added above: Worked; added php-yaml to web container and telnet to db container; dpkg -l php-yaml showed it in web container (and didn't show it in the other project.
- ✅ Add a file (TESTME.txt maybe) to .ddev/web-build and then add it to container with custom Dockerfile that says ADD TESTME.txt / - after ddev start you should find that ddev exec ls -l /TESTME.txt shows the file in the root of the container: This worked in both web and db containers. And the TESTME.txt did not show up in other projects
✅ disable_settings_management: On each Drupal 7, Drupal 8, TYPO3, use disable_settings_management: true, verify settings don't get created: This worked fine. ⚠The only thing that I wondered about was that .ddev/.gitignore never gets created with this setting.
✅ backdrop drush extensions: There doesn't seem to be a programmatic way to do this (See https://github.com/backdrop-contrib/drush/issues/213) but ~/.drush/commands/backdrop/drush appears to have current info, and current commands are supported.
✅ Drush8 version: is 8.3.2.
✅ restore-snapshot is in autocomplete
✅ Drupal 8 config_sync_directory needs to function differently for Drupal 8.8 and 8.9 and 9.0: I composer-built 8.8 and 8.9.x-dev. ⚠ This probably wasn't perfect. Apparently the change was introduced in 8.8 (not 8.9). I tested 8.8 and 8.9 and then 9.0. The reality is that CONFIG_SYNC_DIRECTORY is deprecated in 8.8 but only removed in 9.0. The code behaves correctly given that, and I think it's probably OK.
✅ xdebug stopping too many places: I tested using the php files in #1996 for recreation and it behaved correctly on PHP7.3, 7.4 and 5.6. On PHP 7.0 the bug still exists because of how it was built on upstream. ⚠ There are actually people who use 7.0 and have still stumbled on this.
✅ Magento (1): Use the magento quickstart to install Magento: Installed using docs. Sample data added before importing the sql dump provided with sample data. It looks quite good and is responsive (on WIn10Home WSL2 == Linux). I didn't test import-files. There was something wrong with all 3 versions of the sample data, extra data after end of archive or something. 📃 Docs need pointer to sample data
✅ Magento 2: Use the magento 2 quickstart to install Magento 2. Get sample data. make sure it works: This works great, but additional docs are needed 📃Docs problem: doc says ddev composer create --repository=<https://repo.magento.com/ magento/project-community-edition>, not sure how those angle brackets get in there. 📃 Docs: Explain where sample data is and that you have to switch to developer mode. 📃 Docs need bin/magento setup:store-config:set --base-url="[https://magento2.ddev.site/](https://magento2.ddev.site/)" and bin/magento cache:clean
✅ IS_DDEV_PROJECT: Make sure it works as expected. This worked amazingly well on D8, D7. It was painful how to remember setting up apache+fpm on local machine, but I finally got it. But I couldn't get php5.6 on there to test D6 (but it appeared to work correctly). Backdrop worked pretty well, but it stores much of its config in files, meaning that config from one site could bleed to the other. But overall I was super happy. D8 and D7 I had both sites running at the same time (different ports) with different content. 📃 However, this breaks usage of drush on the host, unless you export IS_DDEV_PROJECT=true, which is a pretty simple thing to do. This is documented at https://ddev.readthedocs.io/en/latest/users/developer-tools/#using-drush-8-installed-installation-on-the-host-computer 👎 drushrc.php doesn't seem to work right with drush uli on host with Drupal 6/7; it doesn't pick up the hostname. drush uli works correctly (after waiting forever) on Drupal 8.8 (with drush/drush installed), which doesn't use drushrc.php, but uses the drush.yml.
✅ Drupal 8 drush.yml should be in <approot>/drush, not sites/all/drush: Works perfectly. Old drush.yml is not removed, added that to release notes.
✅📃Quickstarts: Verify all documented quickstarts (on "latest" (magento and magento2 would have been done above)
- [ ] WordPress/Bedrock 📃 The DB_NAME etc listing is kind of screwy. ddev config --project-type=wordpress might be better than just saying ddev config.
- [x] Drupal 8
- [x] TYPO3 v9
✅ Create .ddev/.gitignore on ddev start.
👎 Subdirectories in .ddev/commands/* should not show up as commands. Unfortunately this doesn't work on web/db although it does work on host commands.
✅ ddev notarized on macOS: Use the techniques at signing_tools to verify that the ddev binary distributed with homebrew on macOS Catalina passes all tests. Try the tarball download and install as well: This all worked great, clean system (testbot). The only oddity was that the tarball-extracted ddev was recognized as notarized, but had the quarantine flag set (because the tarball had been downloaded, and that sets the parent quarantine). AFAICT it worked fine anyway. Quarantine flag link.
✅ ddev exec enable_xdebug: xdebug worked with apache-cgi, vscode, enable/disable both worked.
✅ Make sure utf8mb4 client collation works: Tested with the sample data in #2006 and it worked perfectly.
✅ Pantheon integration: Worked perfectly.
✅ PHP7.3: Make sure default PHP version on new project is PHP7.3

Concerns

⚠I note this output on ddev config: provider.Validate() returned <nil> - I don't think we want that.

📃 It might be reasonable to add links for Magento sample data to the docs. Several Magento 2 improvements noted above.

ddev / ddev

DDEV-Local v1.13 Test Plan #2056

Concerns