Create Repeatable Local Environment

[backlineint]

Package

Not package-specific

Describe the feature request

The current Drupal site included in the monorepo isn't sufficient for most local development use cases. It requires a database seed to be truly useful, is based on Umami (which is great for the Umami example, but not all use cases,) and doesn't actually have a local environment configuration like DDEV or Lando.

To support wider contribution, this repository should have an easily repeatable local Drupal environment that can support at least all of our packages and starter kits. In the future, it should also be possible to run end-to-end testing against this local environment.

Describe the solution you'd like

Some initial thoughts on what this would include:

• A DDEV configuration for Drupal.
• A DDEV configuration that can be used to run node (specifically the starter kits) - this is necessary for Drupal to be able to communicate with the local Next.js site for things like On-Demand revalidation.
• It should be easy to build and rebuild this local environment.
• It should be possible to build versions of a local environment to support our various starters - Basic (app router), Pages, GraphQL, Umami.
• Building this environment should not require any secrets or data not available in this repository.

Describe alternatives you've considered

Our current setup uses either a live external site, or a db export of this site. I don't believe this is practical for the common contributor as some form of credentials would have to be shared.

Additional context

I previously did some initial work on this on this branch: https://github.com/chapter-three/next-drupal/tree/local-recipe - feel free to work from that, borrow ideas from it, or completely ignore it.

[vermario]

I think we faced a similar issue when setting up https://github.com/wunderio/next-drupal-starterkit , where we wanted a way to set up the project (front and backend) using one command, and have both working out of the box.

There we went with using ddev (and lando) to run both the backend and the frontend, so that we could control environment variables.

1. Added a script to generate the consumer and credentials: https://github.com/wunderio/next-drupal-starterkit/blob/main/.ddev/commands/web/generate-oauth-keys.sh
2. used recipes to install the site enable the needed modules, create content types, setup next
3. Env vars are defined in the ddev config: https://github.com/wunderio/next-drupal-starterkit/blob/main/.ddev/config.yaml#L16
4. When the consumer is loaded by drupal, we intercept it using hook_entity_load: https://github.com/wunderio/next-drupal-starterkit/blob/9bdf2a6761402a8c782ff6364a2e4d0eabf675df/drupal/web/modules/custom/wunder_next/wunder_next.module#L19 and https://github.com/wunderio/next-drupal-starterkit/blob/9bdf2a6761402a8c782ff6364a2e4d0eabf675df/drupal/web/modules/custom/wunder_next/wunder_next.module#L73
5. the env vars are then added to settings.php https://github.com/wunderio/next-drupal-starterkit/blob/9bdf2a6761402a8c782ff6364a2e4d0eabf675df/drupal/web/sites/default/settings.php#L53

With all of this, we can spin up the project with one script: https://github.com/wunderio/next-drupal-starterkit/blob/9bdf2a6761402a8c782ff6364a2e4d0eabf675df/setup-ddev.sh

maybe the same kind of logic could be used for this test environment?

[joaogarin]

Is someone working on this one @vermario or @backlineint ? Could try to do something here, we have done similar things as well. Basically have a yarn ddev:init:${starter_name} and that would spin up both backend and frontend giving in the end 2 URLS that are working and running in dev mode so you can do changes in the codebase and have that reflected.

I think when you a dedicated repo for the starters (and not a monorepo) you can already create as much as the folders as possible, here because the idea (as far as I understand) is to spin up different starters dynamically (and some might need different things depending on the starter being initiated) I would probably follow (somewhat) what was started with the scripts putting the fresh created Drupal instance in a separate folder and running from there.

I would still have one single command that spins up both backend and frontend at once both running in ddev

[vermario]

@joaogarin our solution is thought to then being feasible as a base for a real project, maybe overkill for tests here... so if you have a lighter solution it would be great to see it at work!

[joaogarin]

Sure, I was just wondering since the project has multiple starters I think not having a repo per starter makes sense (not sure I might have misunderstood that and no so familiar with wunder's repo)

I added what I played with here #840 please do not feel in any way urged to use it 😆 I am just also happy to check other approaches that's always useful.

Here is a video of how this works (was not able to upload it here maybe its too big)

https://www.youtube.com/watch?v=G2OISONgTWw