fix: ddev config should not change unspecified options, fixes #5882

[stasadev]

The Issue

• The project type is reset to php on running ddev config if no recognized code detected #5882

The bug introduced in

• fix: stop warning about empty app type or docroot creation, fixes #5498 #5631

The expected behavior for ddev config in the various situations:

• config.yaml specifies a set of configs but there's no code to match it (the bug here). (This can be more than just project type I think, docroot as well).

  Running ddev config on existing code should not change existing config options that are not specified.
  For example, when you run ddev config --web-environment-add FOO=bar on a project with the latest config (updating the outdated configuration is mentioned later), it should only change the web_environment option, and nothing else. This is covered in this PR in TestConfigSetValues - this test checks a lot of configuration options, so I think we are safe here.

• config.yaml specifies a set of configs but the code found by DDEV discovers other things (configured for drupal10, finds magento2)

  If the auto-detected project type is different from the one specified by the user, an additional run of ddev config should just show a warning about it, and not add project-specific files of the auto-detected project type. The user's preference should be respected, and if they choose drupal10, the drupal10 settings file (i.e. settings.ddev.php) should be added even if magento2 is automatically detected. This is true until disable_settings_management: true, when all settings are ignored. The project type change is covered in this PR in TestConfigSetValues - if the type is auto changed, we will know about it immediately.

• Initial configuration autodetect, which is good, but of course doesn't work when there's no code.

  ddev config --auto should automatically detect the project type and set other options depending on the project type, but this only applies to the first project config run, all other ddev config --auto should respect the user's decision and only remove deprecated (i.e. outdated) or non-existent config options. This does not require testing, as yaml.Marshal() is used for app.WriteConfig() and all junk configs will always be removed. And auto-detection itself is covered by several tests with Detection in the name.

• config.yaml merges additional config.*.yaml, and you can override config instead of merging with override_config: true

  This is explained in the docs and covered with TestConfigOverrideDetection.

How This PR Solves The Issue

Fixes an issue with overriding the project type when it should not have been changed.
Checks for this bug with a test.

Manual Testing Instructions

1. ddev config --auto && ddev config --project-type drupal10 && ddev config --auto
2. check that project type is drupal10, not php.

Automated Testing Overview

Related Issue Link(s)

Release/Deployment Notes

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-windows-amd64-installer.zip

See Testing a PR

[rfay]

Wow, you got a clean colima/github test!

[rfay]

Thanks for adding test coverage. Please update the OP to state the full expected behavior in the various situations:

• Config.yaml specifies a set of configs but there's no code to match it (the bug here). (This can be more than just project type I think, docroot as well).
• Config.yaml specifies a set of configs but the code found by DDEV discovers other things (configured for drupal10, finds magento2)
• Initial configuration autodetect, which is good, but of course doesn't work when there's no code.
• There may be other permutations, but this basic problem has dogged people from time to time.

Part of the issue is that during the lifetime of DDEV people have moved from initial setup being a git checkout of existing code (with docroot, etc) to where they often start a project with no code at all and a ddev composer create. So the code changes after the configuration is done. And of course, the configuration might not have been right.

[stasadev]

Rebased and updated the OP with the expected behavior.
Looking deeper, I saw that different situations are already covered in other tests, and I simply covered the missing, untested part.

[jpoesen]

👍

Using v1.22.7-48-ge461701c1, this use case now seems to work perfectly on Ubuntu:

• create and change into new project dir
• ddev config, choosing drupal10 project type
• ddev config --http-port=8123
  --> Before this ddev version, project type was reset to 'php'.
  --> Using this ddev version, project type remained 'drupal10` (success!)

Thanks!

[rfay]

Rebased

[rfay]

Rebased.

[rfay]

Thanks, this is great.

I also manually tested with lots and lots of permutations, and it all behaved as expected.