Ddev: Allow overriding config.yaml so that .ddev config can be meaningfully committed to Git

[wizonesolutions]

Is your feature request related to a problem? Please describe.
If I commit the DDEV directory to Git with, say, webcache_enabled: true, then my colleague on Linux will have to turn it off (there is no point in using it on Linux). Same with the upcoming NFS feature.

Ideally, I could specify:

````yaml
additional_config:

• ./local.config.yaml
  ````

and ignore the local config in Git. Then in my local config I could turn on webcache or NFS, or set up additional domains that not everyone needs, etc.

Describe the solution you'd like
````yaml
additional_config:

• ./local.config.yaml
  ````

Additional config is read after .ddev/config.yaml.

Describe alternatives you've considered
A private Git branch?
Just letting the config file be dirty on my local?
Not committing .ddev?

Additional context
N/A

[rfay]

Just FYI, in the next release webcache_enabled is ignored on Linux and Windows. The issue was https://github.com/drud/ddev/issues/1395, the PR was https://github.com/drud/ddev/pull/1390

Does that make this a dup of #1395?

[wizonesolutions]

Not quite. That's only one example. Another colleague wanted to change
ports on his system, a need I don't have on mine.

On Tue, Jan 29, 2019, 16:44 Randy Fay <[email protected] wrote:

Just FYI, in the next release webcache_enabled is ignored on Linux and
Windows. The issue was #1395 https://github.com/drud/ddev/issues/1395,
the PR was #1390 https://github.com/drud/ddev/pull/1390

Does that make this a dup of #1395
https://github.com/drud/ddev/issues/1395?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/drud/ddev/issues/1410#issuecomment-458589170, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAVANGdKQMcKtOEzY3VtBJKwe_Lr5GB0ks5vIGxLgaJpZM4aYRuz
.

[rfay]

Somebody suggested a config.local.yaml, it's a good idea.

[wizonesolutions]

A hard-coded filename would work too, and that might be an easier starting
point. Then everyone knows what it's called.

On Tue, Jan 29, 2019, 18:43 Randy Fay <[email protected] wrote:

Somebody suggested a config.local.yaml, it's a good idea.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/drud/ddev/issues/1410#issuecomment-458636401, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAVANN6e83JM8A1peXDykYQvOqoPSXf1ks5vIIgygaJpZM4aYRuz
.

[wizonesolutions]

Another thought here is per-platform config.

e.g. webcache on macOS, NFS on Windows, neither on Linux. I know some settings will soon be ignored based on platform, but that would still then use native file syncing on Windows if webcache was configured.

config.{linux,windows,mac}.yaml would help people managing dev environments for other developers (for minimum friction) to provide more ready-to-use configuration, so that config.local.yaml would truly be for edge cases where the developers knew what they were doing, like using a different hostname or ports or whatever. I do admit that this is primarily file syncing-motivated, though, as developers could probably just agree on ports and hostnames and then not have to override them. But file syncing is less of an edge case in a multi-platform environment.

[kaystrobach]

go with a convention please, no additional config

[rfay]

@kaystrobach Could you propose a convention? That would be awesome.

[kaystrobach]

I’d vote for config.local.yaml

having different configs for ddev dependend on the host system is out of scope for that issue imho and this would also add lots of options for miss understanding.

[unherz]

Just as a workaround
you can use git update-index to start/stop tracking of this file but keep in mind trhat this is just a workaround.
Stop git tracking of a file:
git update-index --assume-unchanged <file>
Restart git tracking of a file:
git update-index --no-assume-unchanged <file>

A cleaner workaround would be to use a git hook in your project to either ignore the whole file or at least a specific change. For sure you can also apply your perosnal changes as a git hook.

The clean way:
The actual cleanest way (in my opinion) to archive this, as long as there is no feature for it, is to create a private/local yaml file (docker-compose.local.yaml), ignore it per .gitignore and add your config. So everybody in your project can create his/her own docker-compose.local.yaml file without checking it in.

Idea: Maybe there is also a solution with a ddev hook ... 🤔 Im still not sure

[wizonesolutions]

@unherz How do I set e.g. webcache_enabled: true in a local Docker file? We are talking about DDEV config.

[unherz]

@wizonesolutions I got your point. I had a quick look at the implementation and the breaking point is to override a value from the config.yaml .... Im sorry, i forgot about it.
For sure there are ways with git as I mentioned above but there should be also a way to configure it.
For now you can use the git method as a workaround.

Im actually thinking about opening a pull request to fix your issue. Because ddev is go-based, it would be hard to just override the bgsync image since there should be also a health check for this service and there is also a WaitForSync implementation which could lead your project to stuck on a broken config after a timeout.

I might take care of it in the next few hours/days

[unherz]

@wizonesolutions i opened a pull request. Maybe @rfay will have a look at it soon and give some feedback so we can close this issue. In the future i could think about an extra service config for it but atm it should be enough to exclude by OS so windows user can enable it but linux user can ignore this feature

[wandoliver]

@unherz the pr is just webcache-based. here's what i posted in slack today: about the nfs configuration. we share our ddev setup along the team through git. but the nfs activation requires local action on the individual system. so for us it’s not perfect to have that option within the general config.yaml file, as this can provide unexpected behavior with individual developers. is there any option to put that into some additional external configuration file?

so a general option being able to override configurations on a local base would be way more sufficient, as it goes beyond your current pr.

[mfrieling]

I’d vote for config.local.yaml

having different configs for ddev dependend on the host system is out of scope for that issue imho and this would also add lots of options for miss understanding.

I vote for config.local.yml as well or as I suggested some time ago implement the same override schema as you did for docker-compose.overrides.yaml which means:

• config.yaml still is the generated one by ddev config
• Developers can provide additional configs with several overrides, e. g. config.hostnames.yaml (for setting different addtional hostnames or fqdns's) and config.hooks.yaml for adding hooks.

[vagari]

Just to chime in. A config.local.yaml type solution would help me too. I'm in that group that has conflicting ports being overridden (various devs, in various places, so things were left to the 80/443). In my instance I used a docker-compose.override.yaml but it's far from perfect. Just ports doesn't work, just what's exposed doesn't work (I realize that the merging of some environmental variables is by design with docker).

Even with overriding DDEV_ROUTER_HTTP_PORT, DDEV_ROUTER_HTTPS_PORT and their respective expose declarations (which does get things up on the local, available ports, and also doesn't work if you try to keep using variables, just if you put the actual ports in all four places) has side effects, like the Successfully started <project-name> Project can be reached at ... doesn't include the port numbers (if the default is 80 & 443). And includes the ports from config.yaml (if they're not 80 & 443). Not the end of the world if you know what's happening. But can bite you if you don't.

Using config.local.yaml or potentially config.*.yaml would be nice to get me away from this unsanctioned setup. ;-)

[alesrebec]

Dealing with the same thing locally.

My vote would go to config.*.yaml.
So all the files that match this form would be loaded after config.yaml and override it (only the env variables that are defined, of course).

P.S.: Don't get me wrong, I'm fine with config.local.yaml too. It would help a lot to get that change in!
Having config.*.yaml would just allow more flexibility now and in the future.

[kaystrobach]

how would you order the overloading of the files? alphabetically?

[alesrebec]

Yes. I was thinking alphabetically.

[Lefaux]

For us a perfect setup would be like this in terms of loading order:

• config.yaml
• config.{windows|osx|linux}.yaml
• config.user.yaml

config.yaml should reflect the base setup of the environment, later on used for ddev live.
config.{windows|osx|linux}.yaml should contain optimizations for the developers on a team (we run a mix of Win10, OSX and various Linuxes).
config.user.yaml is what I consider being part of a .gitignore, because those settings are done per user and do not need to get back to the team.

I don't fully understand the usecase for multiple overrides yet, maybe someone can fill me in here.

[rfay]

PR https://github.com/drud/ddev/pull/1504#issuecomment-475361377 has an approach to this problem. I'd love it if you all could try this out and see if you think it will meet your needs. As described in the PR, it just allows config..yml to be loaded after config.yaml, which you can use in your workflow any way you want.