Fix over-eager project env replacement, for #4197

[rfay]

The Problem/Issue/Bug:

See bug reported in

• Add .env file parsing, fix laravel to use it, fix Shopware 6 overwriting, fixes #3636, fixes #3590 #4197 (comment) Thanks @stasadev

The application .env file replacement (for laravel, shopware, etc.) was matching partials on the key, so

For example, I have DYNAMODB_CONNECTION in my .env (from this package) and ddev thinks it is the same as DB_CONNECTION, and replaced my config with DYNAMODB_CONNECTION="mysql".

How this PR Solves The Problem:

• Use a more sophisticated pattern for replacement
• Add TestWriteProjectEnvFile that covers (hopefully) all the things

Manual Testing Instructions:

Try the env file suggested by @stasadev

Automated Testing Overview:

Added significant test in TestWriteProjectEnvFile

Related Issue Link(s):

• Add .env file parsing, fix laravel to use it, fix Shopware 6 overwriting, fixes #3636, fixes #3590 #4197 (comment)
• Improve Laravel's explicit integration by actually updating the .env file #3636
• Project type shopware6 keeps overwriting APP_URL in .env file #3590

[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

[stasadev]

It works, thank you!

Also, I noticed that:

1. It writes the db config to .env even if you have omit_containers: [db]
2. I use URL from additional_hostnames for APP_URL in Laravel, but it is always overridden with the primary URL (maybe you can use curl to check if APP_URL is already reachable, and do not override it).

[rfay]

Thanks so much @stasadev -

1. Do you think it matters that it writes DB stuff if omit_containers[db]?
2. I recommend using ddev config --disable-settings-management in your situation. Is that adequate for you?

[stasadev]

1. Just noticed it, does not matter to me.
2. Yes, that's exactly what I want 👍

[rahaddon]

@rfay Hey, every time I perform a ddev restart on a laravel project which doesn't have standard ENV vars like DB_USER they are always being either automatically added or overwritten which results in having to undo the changes, is this the desired behaviour? Thanks

[rfay]

That is the expected behavior, but you can just turn it off with settings_management_disabled: true, see https://ddev.readthedocs.io/en/latest/users/usage/cms-settings/

But I'd love to have you explain in more detail why your laravel project doesn't use those so I could understand better.

[rahaddon]

Thank you for getting back to me, does settings_management_disabled: true disable anything else or it is just related to auto config overwrites in the .env file based on the project type?

But I'd love to have you explain in more detail why your laravel project doesn't use those so I could understand better.

We are using a remote staging database environment which is shared between development team members so the credentials are different to those defaults which are auto-populated by DDEV. Each team member has their own unique user credentials to access the database.

[rfay]

I think settings_management_disabled: true will do what you want.

I do recommend using ddev pull to get the database rather than this, as it will prevent unexpected results of using a shared db. Or just sharing a db dump. But I know you've already thought this through.