Something must be wrong with TestHasConfigNameOverride on Traditional Windows #7797
Description
Preliminary checklist
- I am using the latest stable version of DDEV (see upgrade guide)
- I have searched existing issues
- I have checked the troubleshooting guide
- I have run
ddev debug testto include output below
Output of ddev debug test
Expand `ddev debug test` diagnostic information
[COPY-PASTE HERE THE OUTPUT OF `ddev debug test`]
Expected Behavior
Our tests shouldn't have left-over projects that can't be deleted easily.
Actual Behavior
See https://buildkite.com/ddev/ddev-windows-mutagen/builds/5570#019a4fd3-03db-4c33-8db0-bd1cca2c86d0
I keep finding the below situation on Traditional Windows, where a project from TestHasConfigNameOverride is somehow leftover.
Unfortunately, this always ends up breaking TestCmdList later (which has very specific expectations concering existing projects)
testbot@tb-win11-10 MINGW64 ~
$ ddev list
┌─────────────────────────────────────┬─────────┬────────────────────────────────────────────────────┬─────┬──────┐
│ NAME │ STATUS │ LOCATION │ URL │ TYPE │
├─────────────────────────────────────┼─────────┼────────────────────────────────────────────────────┼─────┼──────┤
│ TestHasConfigNameOverride2304701108 │ stopped │ ~/tmp/ddevtest/TestHasConfigNameOverride2304701108 │ │ php │
├─────────────────────────────────────┼─────────┼────────────────────────────────────────────────────┼─────┼──────┤
│ Router │ stopped │ ~/.ddev │ │ │
└─────────────────────────────────────┴─────────┴────────────────────────────────────────────────────┴─────┴──────┘
testbot@tb-win11-10 MINGW64 ~
$ ddev delete -Oy TestHasConfigNameOverride2304701108
Volume TestHasConfigNameOverride2304701108-mariadb for project TestHasConfigNameOverride2304701108 was deleted
Volume TestHasConfigNameOverride2304701108-postgres for project TestHasConfigNameOverride2304701108 was deleted
Volume TestHasConfigNameOverride2304701108_project_mutagen for project TestHasConfigNameOverride2304701108 was deleted
Project TestHasConfigNameOverride2304701108 was deleted. Your code and configuration are unchanged.
Optionally, run `docker builder prune` to clean unused builder cache.
testbot@tb-win11-10 MINGW64 ~
$ ddev list
┌─────────────────────────────────────┬─────────┬────────────────────────────────────────────────────┬─────┬──────┐
│ NAME │ STATUS │ LOCATION │ URL │ TYPE │
├─────────────────────────────────────┼─────────┼────────────────────────────────────────────────────┼─────┼──────┤
│ TestHasConfigNameOverride2304701108 │ stopped │ ~/tmp/ddevtest/TestHasConfigNameOverride2304701108 │ │ php │
├─────────────────────────────────────┼─────────┼────────────────────────────────────────────────────┼─────┼──────┤
│ Router │ stopped │ ~/.ddev │ │ │
└─────────────────────────────────────┴─────────┴────────────────────────────────────────────────────┴─────┴──────┘
And, perhaps related , ddev delete -Oy TestHasConfigNameOverride2304701108 doesn't make it to away, as shown.
ddev stop --unlist -a also doesn't make it go away
There are no containers stopped or otherwise.
The project_list.yaml:
$ cat ~/.ddev/project_list.yaml
testhasconfignameoverride-override:
approot: C:\Users\testbot\tmp\ddevtest\TestHasConfigNameOverride2304701108
The project's config.yaml:
testbot@tb-win11-10 MINGW64 ~/tmp/ddevtest/TestHasConfigNameOverride2304701108
$ head .ddev/config.yaml
type: php
docroot: ""
php_version: "8.3"
webserver_type: nginx-fpm
xdebug_enabled: false
additional_hostnames: []
additional_fqdns: []
database:
type: mariadb
version: "10.11"
ddev describe -j TestHasConfigNameOverride2304701108
does in fact describe the project. But ddev delete does not remove it.
ddev delete -Oy testhasconfignameoverride-override
does in fact delete the project
Steps To Reproduce
At least on traditional Windows, you can repro by creating ~/.ddev/project_list.yaml with
testhasconfignameoverride-override:
approot: C:\Users\testbot\tmp\ddevtest\TestHasConfigNameOverride2304701108
Anything else?
I assume we must have two different ways of identifying a project, one used by ddev delete and another by ddev describe
- I suspect this is worth debugging and getting to the root of the problem.
- TestCmdList could also be made more robust. It's not hard.