Initial test and some ideas

[shaal]

I tested this repo with a Drupal project - https://github.com/mherchel/fldc22

• This Drupal project has docroot as web, I had to manually update .ddev/config.yaml and run ddev restart, perhaps we should ask the user, or find it automatically?
• I had a copy of the database, so I manually imported database (might be not so trivial, perhaps we can add a README with common next steps
• The project did NOT update web/sites/default/settings.php to include ddev's special settings
• Gitpod's VSCode Source Control panel did not track any updates I made in the Drupal project (but running git status in terminal worked as expected). We can take the settings for that from DrupalPod.

We should probably add a script that can make projects independent of ddev-gitpod-launcher. The script would:

• Grab all current setup (which we assume is successful in Gitpod)
• Create ddev config and a new .gitpod.yml
• Add it to the current project, for the user to push

[shaal]

I stopped and restarted a workspace, and I see what you already noticed. command tasks are running every time a workspace open.

In DrupalPod I solved it in this way -

• The last command is writing a special file /workspace/drupalpod_initiated.status https://github.com/shaal/DrupalPod/blob/main/.gitpod/drupal/drupalpod-setup.sh#L306

• The first command is checking if that special file already exist, to know if setup should run or be skipped. https://github.com/shaal/DrupalPod/blob/main/.gitpod/drupal/drupalpod-setup.sh#L62

[rfay]

Thanks for taking it for a spin!

• ddev config --auto will normally figure out docroot and project type for most projects. In the project you provided, there's no index.php in the web directory, so that's why it doesn't detect adequately. Is the problem that this repo needs a composer install before anything else can be done? (This is also the reason no settings.ddev.php was done)
• I'm super interested in how you change vscode to track the actual subdirectory. I figured that was impossible.

Thanks for the feedback. drupalpod_initiated.status should work fine.

PRs welcome here, this is expected to need to mature.

It seems like the biggest thing is the need to run a composer install before doing anything else (even before running ddev start) or perhaps removing the .ddev and ddev config --auto after the composer install.

[rfay]

I think all the concepts here are now tracked in issues or PRs, right?