Error on ddev start when docroot folder isn't present

[helhum]

What happened (or feature request):

feature request

It would be nice to be able to do ddev start even if the configured folder for docroot isn't present.

Current I get:

$ ddev start
Failed to start: error restoring AppConfig: no siteName given 

What you expected to happen:

ddev start starts without errors when configured docroot isn't present
I would expect this folder to be created instead of seeing an error message.

How to reproduce this:

.ddev/config:

APIVersion: "1"
name: test
type: php
docroot: public
php_version: "7.1"
webimage: drud/nginx-php-fpm-local:v0.9.0
dbimage: drud/mysql-local-57:v0.6.3
dbaimage: drud/phpmyadmin:v0.2.0
provider: default

$ ddev start
Failed to start: error restoring AppConfig: no siteName given 
$ mkdir public
$ ddev start
Starting environment for test... 
…

Please use a complexity rating of 1-5 (5 is high) for a feature request. (High complexity implies more PR planning)

1

[helhum]

Side note ddev config complains when specified docroot dir does not exist, but I would rather have that command create it instead.

Reasoning: This folder might be created (and filled with generated files) on pre-start hooks

[rickmanelius]

Related to #570 (or at least surfaced during the testing of the upstream issue).

[rickmanelius]

I see what you're getting at because this is a chicken/egg problem based on a composer based build where the pre-start hook would generate the folder. However, ddev is currently erroring out because it's attempting to verify the folder earlier on in the process. A potential solution would be to not perform the check until AFTER the pre-start hook. However, there is one other use case that would fail. In the GUI version of DDEV we provide a file brower for the end-user to specify the docroot. We did this consciously to avoid situations where someone misspells the name when selecting it would also be faster and easier. In that situation, we would need to revert back to a text input on the form field OR require the end-user to generate the directory ahead of time.

We need to think about this one a little bit...

[rickmanelius]

Throwing out some additional ideas/concepts. It would be equally possible to have a TYPO3 specific post-configuration step where, once ddev config has finished running, a directory is created if config.yml specifies a docroot that doesn't exist. This would at least keep the test consistent.

[rickmanelius]

Digging around to see what the typical composer based build process was for TYPO3 and I stumbled across this article that shows a step through. Posting it here as a reference https://typo3.com/blog/how-to-install-typo3-using-composer-in-less-than-5-minutes/.

[rickmanelius]

Going through this tutorial was valuable but seems like this boils down to at what stage ddev would typically come in the initial repo creation process. Note there is another path here https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_8-7/INSTALL.md. So I summarize this by simply asking if it would be more typical/common/better for a user to already have run an initial composer install before they would even proceed with configuring ddev or is adding the build in the pre-start hook more likely? If it's the latter, then the generation of that initial folder OR altering the check for said folder would be the two proposed paths forward.

[helhum]

Thanks a bunch @rickmanelius for the detailed analysis on the impact of this.
Reading those, I came to the conclusion that it would be too much effort with too little benefit.

Most TYPO3 projects will come with a document root folder anyway and for the rest having the requirement that this folder exists upfront is totally fine. I mentioned it here, because it was one hurdle I needed to take for the setup I tried, but I rather make a not in the documentation than changing the workflow of ddev.

Maybe @psychomieze or @wmdbmattes can have a look here just to be sure, but I'm closing it for now.