ddev v1.19.0 test plan - community help requested!

[rfay]

It's testing time again here in the DDEV-Local factory. We love community help with every item that is interesting or relevant to you, and just using the release candidates is hugely helpful, because you may stumble across something in your regular workflow. Please use ddev v1.19.0-rc2 or later for your testing (or brew install --HEAD ddev).

I don't think in general you'll have trouble using this in your daily workflow, so would love you do do that. You can switch back and forth , see How can I install a specific version of DDEV in the FAQ.

If you find a bug that you're pretty sure is a bug, then [just open an issue for it](https://github.com/drud/ddev/issues/new?assignees=&labels=&template=Bug_report.md&title=).

To give feedback or ask questions, please just reply on this issue or discuss in [discord](https://discord.gg/hCZFfAMc5k) or another other support channel.

I am maintaining the provisional release notes for v1.19.0 and would love any comments on those.

1. ddev debug dockercheck

2. ddev debug test

3. $PATH change inside web container using homeadditions/.bashrc.d/path.sh (docs)

4. ddev exec and custom web commands can behave much better in combination with quotes, see 'ddev composer', ddev exec, and shell commands like ddev drush do not support quotes, breaking lots of things #2547

5. ddev get --list and ddev get --list --all

6. ddev get now provides access to tested and supported services/recipes (see docs). Try each official recipe:

   1. ddev get --list
   2. ddev get drud/ddev-beanstalkd
   3. ddev get drud/ddev-memcached
   4. ddev get drud/ddev-redis
   5. ddev get drud/ddev-drupal9-solr

7. ddev service enable and ddev service disable swap docker-compose.<service>.yaml in and out of the .ddev directory. Test out.

8. Database configuration changes from mariadb_version and mysql_version to database: mariadb:10.5 and database: mysql:5.7 and database: postgres: 14.

   1. Test several items in .ddev/config.yaml
   2. Test several items using ddev config --database=postgres:13 for example
   3. Existing config.yaml usages of mariadb_version and mysql_version should still work.

9. Postgresql support: Use database type postgres:9 through postgres:14 and make sure it works where needed. (Snapshots not allowed on postgres:9)

   1. ddev export-db
   2. ddev import-db
   3. ddev snapshot
   4. ddev snapshot restore
   5. General usage.

10. macOS: Use ddev with Colima

11. windows WSL2: Use ddev with inside-wsl2 installation of docker and with Docker Desktop turned off. (docs

12. Test with remote docker instance (docs). You may want to try this with a VM running docker.

13. Bare in-container hostnames: You can (once again) use in-container hostnames like db or solr without having to use fully-qualified names like ddev-<project>-db. Verify that ddev web container has no ambiguity even without links. See testing instructions in Use simple container name as hostname inside docker network (use "db" instead of "ddev-<project>-db") #3403

14. Test improved WordPress setup per Fixes DDev WordPress Config Files for Override & Coding Standards, fixes #2795 #3468. See manual testing instructions there.

15. Gzipped database snapshots:

    1. Test snapshot and snapshot restore
    2. Test restoring an existing directory-based snapshot

16. ddev start now tests available disk space against an absolute value (5GB) rather than a percentage. Test to make sure that it does flag low values. This can be done with artificially using space or by altering the value in nodeps/values.go (Also see The absolute available space value was wrong for checking docker disk space #3646)

17. Verify that graphicsmagick is installed in web container

18. Fresh Drupal 10 install should get PHP Version 8.1

19. Fresh Laravel install should get PHP Version 8.0

20. ddev tableplus should work for both mysql/mariadb and postgres projects

21. nodejs and nvm support

    1. Override nodejs version in .ddev/config.yaml
    2. Use ddev nvm to get any nodejs version.

22. Gitpod users should be able to use Xdebug, Remove special handling for gitpod getting host.docker.internal #3597

23. ddev delete should delete any volume named in any docker-compose.*.yaml

24. when mutagen_enabled, ddev now mounts upload_dir into container using regular docker bind-mount.

25. Verify that segment/amplitude reporting is working adequately.

26. A new ddev project should be able to start up even if there’s no internet (assuming images have been downloaded already)

27. ddev debug download-images should download default images (maybe more???) and also get docker-compose and mutagen.

28. New ddev php command

29. New ddev debug clean command (WIP, not in v1.19.0-rc1)

30. Ability to use ddev config global --no-bind-mounts to not use docker bind mounts at all (for remote machines, where $DOCKER_HOST is used, etc.) Test with a remote machine.

31. docker-compose v1: Use ddev config global --required-docker-compose-version=v1.29.2 and verify normal usage.

32. Casual Webhosting: Verify that casual webhosting feature is working OK.

[cmuench]

Just started to test Magento 2.4. My test project started without any issues and without any modification.

[rfay]

1. ✅ ddev debug dockercheck worked fine on WSL2. The first time I tried it I did see Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 192.168.65.5:53: no such host but I've seen that before on Docker Desktop (quite a lot) and it didn't repeat later.
2. ✅ ddev debug test worked fine (WSL2). The launch took a little longer than expected because I had the WSL2 set up to use X instead of launching on the Windows browser.
3. ✅Adding to $PATH: This worked fine. I added a .ddev/homeadditions/.bashrc.d/path.sh with contents export PATH=$PATH:/some/random/wsl/path and after ddev restart then ddev exec 'echo $PATH' showed ~/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/www/html/vendor/bin:/var/www/html/bin:/some/random/wsl/path and ddev ssh with echo $PATH showed same. (wsl2)
4. ✅ ddev exec --raw mysql -e "SHOW DATABASES;" and ddev mysql -e "SHOW DATABASES;" worked fine. (wsl2 test)
5. ✅ddev get --list shows the 4 (to-date) official add-ons. There are currently no unofficial add-ons, but if I temporarily add the label ddev-get to one, it shows up in ddev get --list --all (wsl2 test)
6. ✅ddev get recipes: (tested on gitpod)
   1. ddev get --list shows 4 existing official items
   2. ddev get drud/ddev-beanstalkd works and I can connect to the service, but don't know enough about beanstalkd to do more.
   3. ddev get drud/ddev-memcached works and I can connect to port 11211 and issue commands like stats
   4. ddev get drud/ddev-redis works and I can use the provided "redis-cli" command to do ddev redis-cli INFO
   5. ddev get drud/ddev-drupal9-solr works and I went through the Drupal installation technique and it all seemed to be doing what it should.
7. ✅ ddev service disable redis worked. ddev service enable redis turned it back on. ddev service enable junk gave a reasonably understandable "No docker-compose.junk.yaml found in /workspace/d9simple/.ddev/.disabled-services". ddev service disable junk gave "Service junk does not currently exist in .ddev directory". Those could be more consistent. 👎 . (tested on gitpod)
8. ✅ Database Configuration Changes: I pulled up a WordPress project that hadn't been touched by v1.19. I was able to start it without changing the config.yaml, and was able to restore a snapshot from it, and create snapshots. ddev config --auto changed the database line from mariadb_version: 10.3 to database: etc.
9. ✅ Postgresql: I didn't go through all the versions, although there's test support for all versions. I have been using postgres:14 almost exclusively with drupal9, and have done lots of snapshotting, etc.
10. ✅ macOS ddev with colima... I've been using it consistently and have had no trouble. Some days docker desktop never gets started. There are significant and persistent problems with tests as described in Intermittent failure to release port bindings abiosoft/colima#189 but they don't seem to affect ordinary users.
11. ✅ docker installation inside wsl2; Worked fine, but I'll add a couple more notes to the instructions.
12. ✅ Remote docker instance.
    * Had to go back and figure out how to set up a docker service with port open. Used link with a raspberry pi. But the place to do the edit was in /etc/systemd/system/multi-user.target.wants/docker.service instead of what it says in the article. The new line was ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 --containerd=/run/containerd/containerd.sock
    * On client side (macbook air), create a docker context with docker context create pi --docker host=tcp://pi.ddev.site:2375 and docker context use pi
    * ddev config global --no-bind-mounts --mutagen-enabled - No bind mounts are possible on a remote system, so we have to use mutagen to get everything over there.
    * I got it to work, but it was painful and I haven't thought about it for some time. The webserver is the remote docker instance (where ddev-router is actually running). The hostnames need to be the same in both the client and the remote machine (or preferably in DNS). I also fooled myself because I hadn't used the pi for many months and there was an existing site on it with the same name as I was trying to use. And that caused errors I had to debug through.
13. ✅ Bare in-container hostnames: I added the solr add-on to 3 different projects and started them. Then I used ddev exec ping solr on each, and in every case it showed the correct response/container.
14. ✅ Test improved WordPress setup per Fixes DDev WordPress Config Files for Override & Coding Standards, fixes #2795 #3468. In an existing WP project I removed wp-config.php and wp-config-ddev.php. Then I did an install with a different table prefix. It created a new wp-config.php. Then a ddev start created the wp-config-ddev.php, and adding the required include worked fine, and it respected the preconfigured table prefix.
15. ✅ Gzipped database snapshots: Tested the directory-based restore in #8. Tested snapshot and restore with new style.
16. ✅ ddev start now tests available disk space against an absolute value (5GB) rather than a percentage. Test to make sure that it does flag low values. This can be done with artificially using space or by altering the value in nodeps/values.go (Fixed in The absolute available space value was wrong for checking docker disk space #3646)
17. ✅ Verify that graphicsmagick is installed in web container: ddev exec gm -help GraphicsMagick 1.4 snapshot-20210721 Q16 http://www.GraphicsMagick.org/
18. ✅ Fresh Drupal 10 install should get PHP Version 8.1. This worked fine. I note 👎 that there is no quickstart in the docs yet. (There also seems to be no composer create-project capability yet. Also 👎 ddev drush doesn't work. (Fixed in ddev drush should be available for drupal10 #3655)
19. ✅ Fresh Laravel install should get PHP Version 8.0: In my laravel project I rm .ddev/config.yaml and ddev config --auto and it used php8.0.
20. ✅ ddev tableplus should work for both mysql/mariadb and postgres projects: It worked in both. However, I see there's a stray set -x in there, will add it to ddev drush should be available for drupal10 #3655.
21. ✅ nodejs and nvm support - nvm doesn't seem to work right at all. The nvm version set doesn't persist even for a minute.
    1. I set nodejs_version: 12 and ddev restart and ddev exec node --version: v12.22.10 (OK)
    2. Use ddev nvm to get any nodejs version: ddev nvm install 6 : This seems to work, but then when you ddev ssh it's back to the system version. And I see inside /usr/local/nvm an additional version of everything, /usr/local/nvm/d9-web. (fixed in Improve ddev nvm persistence and availability, starting with no internet #3664)
    3. ❌ I also happened to notice that ddev isn't populating the .ddev/web-build or .ddev/db-build directories with the expected README and examples. It seems these are (oddly) only populated during ddev config
22. ✅ Gitpod users should be able to use Xdebug, Remove special handling for gitpod getting host.docker.internal #3597: Worked fine. I launched gitpod session and stopped at a breakpoint.
23. ✅ ddev delete should delete any volume named in any docker-compose.*.yaml: I added a service with 3 junk volumes; they were created on start, and on delete I saw: "Deleting third-party persistent volume ddev-junk_junk1...Deleting third-party persistent volume ddev-junk_junk2...Deleting third-party persistent volume ddev-junk_solr...Deleting third-party persistent volume ddev-junk_junk"
24. ✅ when mutagen_enabled, ddev now mounts upload_dir into container using regular docker bind-mount: I enabled mutagen on a Drupal 9 project and ddev restart. Then looking inside the container, df -h /var/www/html showed the mutagen volume, and df -h /var/www/html/web/sites/default/files showed the direct docker mount.
25. ✅ Verify that segment/amplitude reporting is working adequately: Amplitude shows 29 users on v1.19.0-rc1 in the last 7 days, so this seems to be working.
26. ✅ A new ddev project should be able to start up even if there’s no internet (assuming images have been downloaded already): Failed: the nvm update failed "nvm is already installed in /usr/local/nvm, trying to update using git" (fixed in Improve ddev nvm persistence and availability, starting with no internet #3664)
27. ✅ ddev debug download-images should download default images (maybe more???) and also get docker-compose and mutagen: Worked fine but 👎 does not download mutagen. But OOOH, it got all the 3rd-party images, and got the right database image!
28. ✅ New ddev php command: ddev php -i shows all. ddev php -r 'echo "hi";' works.
29. ⏳\ New ddev debug clean command (WIP, not in v1.19.0-rc1)
30. [tested in #12] Ability to use ddev config global --no-bind-mounts to not use docker bind mounts at all (for remote machines, where $DOCKER_HOST is used, etc.) Test with a remote machine.
31. ✅ docker-compose v1: Use ddev config global --required-docker-compose-version=v1.29.2 and verify normal usage: This now works with latest, but didn't work with v1.19.0-rc1. Tested on gitpod.
32. ❌ Casual Webhosting: Verify that casual webhosting feature is working OK: It fails on startup because it uses sudo.
    sudo mkdir -p /mnt/ddev-global-cache/bashhistory/gchistory-web /mnt/ddev-global-cache/mysqlhistory/gchistory-web /mnt/ddev-global-cache/nvm_dir/gchistory-web /start.sh: line 78: sudo: command not found ✅ Fixed in Make hardened images work and provide test #3680: I manually tested this on my own website and also with just ddev config global --use-hardened-images, also locally with regular project, both with and without existing installed nvm.

[cmuench]

On my Arch Linux (amd64) machine.

✅ ddev get drud/ddev-beanstalkd
✅ ddev get drud/ddev-memcached
❌ ddev get drud/ddev-redis
✅ ddev get drud/ddev-drupal9-solr

Redis service -> "No releases found for ddev-redis"

[rpkoller]

Tested on MacOS 10.13.6, Docker 2.4.0.0. and Mutagen activated.

1. ✅ worked fine. excellent addition.
2. ✅ works fine. an indepth option checking the setup. love it. the only question i wonder. i've ran the command in the directory of an already running project. if i take a look at the .ddev/config.yml file there is no indication of the debug project that is recommended deleting.
3. ✅ .ddev/homeadditions/.bashrc.d/path.sh with contents export PATH=$PATH:/some/random/path in my projects homeadditions like you did in your example @rfay but the file got removed on startup. not sure why it gets removed. the file had no #ddev-generated statement in it neither. there is also some odd behaviour with .bash_aliases as well i'Ve tried along the line Update: After wiping all my containers and starting from scratch with only one started project I've added ~/.ddev/homeadditions/.bashrc.d/aliases.sh in the global ddev directory and added several aliases (for example alias ll='ls -lah') and tried alongside for the project homadditions directory adding the path.sh file that failed before. ddev exec 'echo $PATH'showed that the path was added correctly and after ddev ssh the alias for ll lead to the correct directory output.
4. ✅ works. only the indefinte running of the command after successfully finishing the task remains but that seems something fringe on my installation somehow.
5. ✅ works. one feedback about the current iteration. i wouldn't place the asterisk at the end of the description line. the user has to scan the whole description line figuring out if it is an official or community add on. the information has to be front loaded and the goal should be to have the important information within the first ~11 characters which equals roughly 2 words. therefor i still thing a dedicated third column would be worth to consider with either an empty cell or a cell containing an asterisk. and the column order asterisk, add-on and description.
6. ✅ i can confirm that the redis release couldn't be found No releases found for ddev-redis Update: Redis is working now
   beanstalked:

ddev get drud/ddev-beanstalkd
Downloading https://api.github.com/repos/drud/ddev-beanstalkd/tarball/v1.1.1
v1.1.1_191959826.tar.gz 6.32 KiB / ? [-------------------------------------=------------------------------------------------------------------]  64.72% 0s
if [ "$(arch)" = "arm64" -o "$(arch)" = "aarch64" ]; then echo "This package does not work on arm64 machines"; exit 1; fi

Installed file /Users/danton/Sites/toolbartest/.ddev/docker-compose.beanstalkd.yaml
Downloaded add-on drud/ddev-beanstalkd, use `ddev restart` to enable.
For more information about this add-on visit the source repo at https://github.com/drud/ddev-beanstalkd 

the if statement shoulnd't be shown imho
solr:

$> ddev get drud/ddev-drupal9-solr
Downloading https://api.github.com/repos/drud/ddev-drupal9-solr/tarball/v1.0.1
v1.0.1_1256256353.tar.gz 1.22 MiB / ? [----------------------------------------------------------------------------------=------------------] 12805.27% 0s
docker volume rm ddev-${DDEV_PROJECT}_solr 2>/dev/null || true

Installed file /Users/danton/Sites/toolbartest/.ddev/solr
Installed file /Users/danton/Sites/toolbartest/.ddev/docker-compose.solr.yaml
Executed post-install action chmod +x solr/docker-entrypoint-initdb.d/solr-configupdate.sh.
Downloaded add-on drud/ddev-drupal9-solr, use `ddev restart` to enable.
For more information about this add-on visit the source repo at https://github.com/drud/ddev-drupal9-solr

the docker volume rm line should also be hidden imho. and when restarting the project after ddev get ddev isnt that chatty anymore but now there is no progress indication anymore at all:

beanstalkd Pulling
solr Pulling
memcached Pulling
beanstalkd Pulled
memcached Pulled
solr Pulled

so as a user you have no idea if the dl is stalled or not and if things still advance correctly. after installing and downloading all available images i've applied ddev get for memcached in another project and the image hasn't downloaded a second time. so no surprises and everything behaves as expected.
7. ✅ works. only nitpick. without taking a look at the documentation i first tried ddev service disable drud/ddev-memcached then ddev service disable ddev-memcached and finally ddev service disable memcached. i would have expected ddev-memcached and memcached was kind of unexpected. would it be better to stay consistent with the naming maybe?
8.
9. ✅
Postgres 12
i. ✅ ddev export-db --file=postgres12.sql.gz worked
ii. ✅ ddev import-db --src=postgres12.sql.gz worked
iii. ✅ ddev snapshot worked
iv. ✅ ddev snapshot restore postgres_20220302132857 worked
v. ✅ Manually installed drupal instead of using drush site install and everything went without any problem as well as after restoring a snapshot. ddev psql -c 'CREATE EXTENSION pg_trgm;' works as well

Postgres 9 minimum requirement for drupal 9 is postgres 10 so i stopped at that point

Postgres 10
i. ✅ ddev export-db --file=postgres10.sql.gz worked
ii. ✅ ddev import-db --src=postgres10.sql.gz worked
iii. ✅ ddev snapshot worked
iv. ✅ ddev snapshot restore postgres_20220302132857 worked but the first time i got Failed to restore snapshot postgres10_20220302141731 for project postgres10: failed to start project for RestoreSnapshot: web container failed to become ready: web container failed: log=, err=health check timed out: labels map[com.ddev.site-name:postgres10 com.docker.compose.service:web] timed out without becoming healthy, status= probably too much load workwise for my computer that lead to the timing issue. retried the command then it worked properly
v. ✅ Manually installed drupal instead of using drush site install and everything went without any problem as well as after restoring a snapshot. ddev psql -c 'CREATE EXTENSION pg_trgm;' works as well

17. ✅ graphicsmagick could be found. which gmreturned /usr/bin/gm. and also tested a quick conversion from the gm documentation gm convert -size 120x120 test.jpg -resize 120x120 +profile "*" thumbnail.jpg. worked as well as expected. nice thank you!
18. ✅ Created a new directory and performed a ddev config and set the project type to drupal10. When checking the config.yml file afterwards php_version was set to 8.1
19. ✅ Created a new directory and performed a ddev config and set the project type to laravel. When checking the config.yml file afterwards php_version was set to 8.0 One observation: if i rerun ddev configin the set up laravel directory and change the project type from laravel to drupal10 the type in the config.yml gets updated but the php_version remains at 8.0. Same the other way around. if you set the project type to drupal10 in the first ddev config run in a new directory and the change the type to laravel in a rerun the php_version sticks to 8.1 in that case.
20. ✅ I've tested tableplus with on mariadb based project and one postgres based one. both work without any complaint. One observation: ddev sequelpro has no output and just starts the app. but with ddev sequelacei get:

$> ddev sequelace
+ query=mysql://root:root@127.0.0.1:32789/db
+ open mysql://root:root@127.0.0.1:32789/db -a '/Applications/Sequel Ace.app/Contents/MacOS/Sequel Ace'

and with ddev tableplus i get:

$> ddev tableplus
+ dbtype=drud/ddev-dbserver-mariadb-10.3
+ driver=mysql
+ [[ drud/ddev-dbserver-mariadb-10.3 == \p\o\s\t\g\r\e\s ]]
+ query=mysql://db:db@127.0.0.1:32789/db
+ open mysql://db:db@127.0.0.1:32789/db -a /Applications/TablePlus.app/Contents/MacOS/TablePlus

i think keep things consistent would be the better choice either make all app starts verbose or let all behave like ddev sequelpro. And aside that it might be a good idea to update the error message when an app is not installed like Sequel Ace or Tableplus. When i first tried ddev tableplus i was under the assumption tableplus was a web based solution and was expecting i would get forwarded to a browser window but instead i got:

$> ddev sequelace
Error: unknown command "sequelace" for "ddev"
Run 'ddev --help' for usage.

that way it reads the command sequelace doesnt exist in ddev but instead ddev is unable to find the app in the macos application directory. maybe stating something like DDEV is unable to find Table Plus in the MacOS Applications directory. If you want to download go to www.tableplus.com?
21. i. ✅ changed nodejs_version from the default 16 to 17(17.3.0) in the config.yml file and it worked
ii. ✅ am not very familiar with nvm. tried and tested from a novice perspective. the config.yml was still set to 17. did ddev nvm install 17.6.0 and the version 17.3.0 was updated to the latest available. afterwards i did ddev nvm install 15.14.0 also. ddev nvm ls showed me 15.14.0, 17.6.0 and system available. then i thought system would take me to 17.3.0 with ddev nvm use system but it was 17.6.0as well. so major versions couldnt be encapsuled it looks (meaning ddev installs 17.3.0 with the 17 nodejs_version flag and if i install another version >17.3.0 that becomes the main version). An i was also able to change the node version used to 15 with ddev nvm use 15.14.0. but i then tried to change the nodejs_version in the config.yml to 13 and i got the following on restart:

$> ddev restart
Failed to get project(s): unsupported system Node.js version: '13'; for the system Node.js version ddev only supports [12 14 16 17]. However, you can use 'ddev nvm install' at runtime to use any supported version

switched then to 12and after restart that worked. ddev . node -v returned v12.22.10 and ddev nvm lsreturns

$> ddev nvm ls
       v15.14.0
->      v17.6.0
         system

performed a ddev nvm use 17.6.0 that switched to Now using node v17.6.0 (npm v8.5.1) and did ddev nvm use system afterwards returning Now using system version of node: v12.22.10 (npm v6.14.16). all good :) excellent. Suggestion: would it make sense to add alongside the global cmd nvmalso one for node for convenience and consistency?

[rfay]

@rpkoller thanks so much for your testing! It's going to be a little too messy to discuss these in the issue here, so could we discuss in Discord or slack (Already created thread in discord). Some of the things are misunderstandings (the one about ddev import-db not finding file). Others like not becoming healthy definitely need discussion. I imagine they have to do with the timeout value and your ancient machine, but definitely need discussion. But this issue will die a horrible death if we chase those here. Better to confirm in another venue and open separate issues.

[shaal]

Testing in Gitpod (empty workspace-full environment, Docker version 20.10.12, build e91ed57, Ubuntu 20.04.4 LTS)
Installed ddev with brew install --HEAD drud/ddev/ddev

1. ✅
2. ✅

[h1nds1ght]

21. ❌ nodejs and nvm support - nvm doesn't seem to work right at all. The nvm version set doesn't persist even for a minute.

    1. I set nodejs_version: 12 and ddev restart and ddev exec node --version: v12.22.10 (OK)
    2. Use ddev nvm to get any nodejs version: ddev nvm install 6 : This seems to work, but then when you ddev ssh it's back to the system version. And I see inside /usr/local/nvm an additional version of everything, /usr/local/nvm/d9-web.
    3. ❌ I also happened to notice that ddev isn't populating the .ddev/web-build or .ddev/db-build directories with the expected README and examples. It seems these are (oddly) only populated during ddev config

Not sure how this new option was finally implemented. I use a custom implementation for a longer time, where I just set the environment variable NODE_VERSION in config.yaml and then use a custom post-start script. In this post-start script I then run

curl -s -o- https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash

which on the other hand then again reads NODE_VERSION and installs the desired node version on each restart. So in principle this is sufficient to install for example node 12 (at least for ddev ssh, ddev exec is more complicated):

web_environment:
  - NODE_VERSION=12
hooks:
  post-start:
    - exec: "curl -s -o- https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash"

[rfay]

@h1nds1ght I hope you'll test it and report your findings. If you don't like it a new issue or a discussion in Discord would be great. What it does is the regular install.sh for nvm, but the primary system node version is set with nodejs_version. Docs at https://ddev.readthedocs.io/en/latest/users/cli-usage/#nodejs-npm-nvm-and-yarn.

[h1nds1ght]

I tested it. For me it works perfect within its limits. I can change to node versions 12, 14, 16 and 17 and ddev ssh as well as ddev exec show me the most recent version of the according major version.

This is much better than before, of course, but there also might be people still using deprecated versions like 8. You might say, they can use the new ddev nvm, but I thought it might be nice to set whatever node version you want in config.yaml, therefore I shared my approach with NODE_VERSION.

But what seems new is that my approach doesn't work anymore with v1.19, I always get node version 12, because my nvm at $HOME is superseded by an nvm at /usr/local/nvm

[rfay]

Thanks - in that case you haven't tried nvm, which allows anything. Please try out ddev nvm or just nvm inside the container. I'm also working on making ddev nvm more robust right now, so there will be another step before the v1.19.0 release.

[rfay]

I'm working on ddev exec recognizing the nvm version, that will be in rc2. Yes, you have to use ddev nvm if you want an unsupported node version. This works the same as on a server. Typically there's a "system" node version, installed with apt or whatever, and then nvm takes over if you need more.

And there is no way for you to implement that automatically to nodejs_version? I.e if node version is not within [12, 14, 16, 17] install the given version with nvm on ddev start?

The nodejs_version is implemented at image build time, before nvm can even exist. There's probably some way to do what you ask, but we'll see how this goes for now. I suspect that even just the config.yaml option will work great for lots of people, and then nvm users will probably be happy too.

Also see

• Improve ddev nvm persistence and availability, starting with no internet #3664
  Would love to have you test that on gitpod or local. Gitpod: https://gitpod.io/#https://github.com/drud/ddev/pull/3664, downloadable artifacts will be at https://github.com/drud/ddev/actions/runs/1938676240

[rpkoller]

Rerun of most of the steps with RC3 - Tested on MacOS 10.13.6, Docker 2.4.0.0. and Mutagen activated.

1. ✅
2. ✅ i would extend ddev is working output. You will want to delete this project with ddev delete -Oy tryddevproject-22972 to something like ddev is working. You will want to delete this project and associated docker files with "ddev delete -Oy tryddevproject-22972" and manually remove the source files with rm -r ~/tmp/ tryddevproject-22972 until Improve ddev debug test #3679 has landed. that way the user is informed that there is a new directory and php file created when running ddev debug test
3. ✅
4. ❌ ddev . drush role-add-perm authenticated 'administer comment types' returns Too many arguments, expected arguments "command" "machine_name" "permissions". Failed to execute command drush role-add-perm authenticated administer comment types: exit status 1 while ddev drush role-add-perm authenticated 'administer comment types' works (without the hang repeatedly ironically). ddev exec --raw mysql -e "SHOW DATABASES;" and ddev mysql -e "SHOW DATABASES;"also works ( the examples from the comment of @rfay) BUT

$> ddev . mysql -e "SHOW DATABASES;"
ERROR 1044 (42000): Access denied for user 'db'@'%' to database 'DATABASES'
Failed to execute command mysql -e SHOW DATABASES;: exit status 1

seems the . shortcut causes issues in the context of ddev exec and quotes
5. ✅ small nitpick. i would go with @weitzman suggestion from discord: https://discord.com/channels/664580571770388500/950462049572491364/950482637720522822 changing the command at a later point would cause even more confusion. instead using the desired syntax from the start would prevent any confusion. and i agree with him that ddev service list would be the more consistent and clear syntax.
and readability wise the list is still difficult to comprehend (see my initial comment and thoughts about - i guess no pressing need to solve that for 1.9.0 but it should be improved at a later point). cuz currently the user has the table/list of add-ons. at the bottom the user has to read then the disclaimer that add-ons marked as official have an asterisk. now eyes move up again and have to scan the first line until the end, which is several tenth of characters until you find directly attached to the last character of the last word the asterisk. so scan/read wise as well as cognitively the load is still quite high. and i dont know if there are any ddev screen reader users but for those it would be even more difficult to navigate. still think a dedicated third column on the left of the add on column just for an asterisk would provide the most clarity.
6. ✅ small cosmetic nitpicks and one question. the get command works for all four official add ons. only for beanstalked you have the following line shown which is unnecessary if [ "$(arch)" = "arm64" -o "$(arch)" = "aarch64" ]; then echo "This package does not work on arm64 machines"; exit 1; fi and for solr the following line docker volume rm ddev-${DDEV_PROJECT}_solr 2>/dev/null || true. those could be hidden.
and by accident i've entered one of the get statements a second time. should it be noted by ddev that a docker-compose yaml is already in place for that add-on instead of just running the install process a second time? and that brings me to my question how things are handled if an add on is upgraded upstream at some point? is there also an update mechanism or notification? otherwise if something is fixed and or improved to the official add-on that never gets noticed by the user downstream?
7. ✅
8. ✅
9. ✅
10. no colima installed
11. no windows
12. not tested
13. ✅
14. ✅
15. ✅
16.
17. ✅
18. ✅
19. ✅
20. ✅

[rfay]

Calling this one good. Thanks to all of you for testing - it made a huge difference. Followups are welcome, of course. If you thing something should still be addressed, feel free to comment here or open a new issue.