Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"ddev config" doesn't look for an existing .ddev/config.yaml #1158

Closed
rfay opened this issue Oct 6, 2018 · 4 comments
Closed

"ddev config" doesn't look for an existing .ddev/config.yaml #1158

rfay opened this issue Oct 6, 2018 · 4 comments

Comments

@rfay
Copy link
Member

rfay commented Oct 6, 2018

Describe the bug

ddev config does not do the check to see if it's already in a project. Instead it will always try to create a .ddev/config.yaml in the current directory. (The other commands all call utils.CheckForConf() at some point).

ddev config should call CheckForConf() and if not found, create the config in the current directory.

To Reproduce

  • Create a project
  • cd into a subdirectory of the project
  • ddev config
  • Note that the new .ddev is created in the subdirectory.

Expected behavior

ddev config should find the master directory to config if it's already configured.

Additional context

I think this dates from the time that ddev config was assumed never to be run more than once.
@mglaman
Copy link
Contributor

mglaman commented Nov 1, 2018 •
edited

So to fix this: ddev config needs to look upwards for the existing project just like start/stop/exec, et do?

@rfay
Copy link
Member Author

rfay commented Nov 1, 2018

Yes, exactly.

@andrewfrench andrewfrench self-assigned this Nov 1, 2018
@andrewfrench andrewfrench removed their assignment Nov 1, 2018
@andrewfrench
Copy link
Contributor

The bulk of this is fixed by replacing os.Getwd() with ddevapp.CheckForConf() to search through parent directories for an existing config:

https://github.com/drud/ddev/blob/b139f191f5171f75c7066fd2bf0fa4814c5dda65/cmd/ddev/cmd/config.go#L198

But that one-line fix seems to break the assumptions of the interactive config (specifically docroot and apptype detection). I think that's easily fixable by working relative to the detected app root. It'll also take some wording changes in the docroot prompt, as "current directory" will end up being misleading.

@rfay
Copy link
Member Author

rfay commented Nov 2, 2018

👍

@andrewfrench andrewfrench mentioned this issue Nov 16, 2018
Merged
@rfay rfay mentioned this issue Dec 13, 2018
Closed
8 tasks
@dclear dclear removed the actionable label Dec 19, 2018
rfay added a commit to rfay/ddev that referenced this issue May 7, 2019
@rfay
Revert "Look in parent directories for an existing .ddev/config.yaml, f…
f02d8e9 
…ixes ddev#1158 (ddev#1275)"

This reverts commit 7c8310e.
rfay added a commit to rfay/ddev that referenced this issue May 10, 2019
@rfay
Revert "Look in parent directories for an existing .ddev/config.yaml, f…
9af2479 
…ixes ddev#1158 (ddev#1275)"

This reverts commit 7c8310e.
rfay added a commit to rfay/ddev that referenced this issue May 10, 2019
@rfay
Revert "Look in parent directories for an existing .ddev/config.yaml, f…
f349c49 
…ixes ddev#1158 (ddev#1275)"

This reverts commit 7c8310e.
rfay added a commit that referenced this issue May 10, 2019
@rfay
Revert parent config search, prevent directory destruction, hopefully f…
16f109e 
…ixes #1574 (#1576)

* Revert "Look in parent directories for an existing .ddev/config.yaml, fixes #1158 (#1275)"

This reverts commit 7c8310e.

* Remove the behavior of ddev composer create --no-interaction that allows full deletion without confirmation

* Add error check to make sure they don't run it in homedir

* Warn user of ddev config if a parent directory has .ddev/config.yaml in it

* Add tests to make sure subdir and homedir config behaves properly

* Clean up ~/.ddev/config.yaml that might exist
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rfay @dclear @mglaman @andrewfrench