Formalize support of contributed recipes, and add a command to add them

[shaal]

Is your feature request related to a problem? Please describe.

• When I want to use a ddev-contrib recipe, I have to follow multiple steps manually. that manual process is prone to errors.
• ddev-contrib is not adequately structured, tested or maintained.
  • Structure needs to be formalized, so that files from a recipe can be reliably added to a repo.
  • Each recipe needs a test. We could probably use bats tests, which we use for some container tests and also for testing quicksprint. I imagine that rfay would have to write the tests, as adding a test requirement for casual contributors might be too onerous.

Describe the solution you'd like

• Restructured repo for supported recipes. Perhaps a new ddev-recipes repo? Or a "supported" section in ddev-contrib?
• Documentation of supported recipe format
• Tests for supported recipes.
• Updated docs for ddev to point to the supported recipes
• ddev command; you could run ddev recipe <link_to_repo/directory> to implement recipes in my current setup.
  DDEV will download for me the recipe and set it up correctly. More or less.

While an official recipe repo is the best, I think allowing other users to host ddev recipes would be awesome, as long as they keep the official TBD ddev recipe structure.

For example, to implement PHP 8.1 recipe, I should be able to run -
ddev -recipe https://github.com/rfay/ddev-contrib/tree/20210622_php8_1/docker-compose-services/php8_1

[rfay]

The real issue here is not the command for ddev, it's the structure and maintenance of the recipes.

[rfay]

I edited the title and OP quite a lot, hope it's OK.

[rfay]

And this is super, super exciting. Huge project, but super exciting. Great initiative.

[rfay]

I think maybe just moving supported recipes right into ddev would be the ticket.

[tyler36]

Any action on this?

I'm thinking we need templates for:

• documentation
• docker-compose
• commands

Does this mean all supported recipes will require tests?
Would configuration be moved into the main config.yaml?
Eg. Postgres image version moved from docker-compose.postgres.yaml into a DDEV variable

[rfay]

I'd love to see this happen in this release cycle. If you or anybody else wants to pioneer the approach it's just there waiting!

[shaal]

We should look into "chained" recipes, in case I want my project to use more than 1 recipe.

Example:
A Drupal project + "Solr" recipe + "Multisite" recipe

[jonaseberle]

I have also thought about that. Happy to see this issue here 👍🏽

IMHO it must allow installation from any source, not just the "official" ddev-contrib. That way it becomes very interesting for all kinds of custom commands that are not worth integrating into ddev-contrib.

I would recommend using PHP composer with a custom composer plugin for installation. PHP is what we all know, composer knows versioning, external/intrenal package sources and of course dependencies. Publishing on packagist is extremely easy from any Git source and even easier from Github/Gitlab.
A list of published extensions can be fetched with their API, e.g. https://packagist.org/packages/list.json?type=ddev-extension

That could mean:

• A .ddev/composer.json.
• A composer plugin (acting on a specific package type, e.g. "type": "ddev-extension") that installs everything from a package's ./ddev directory into the current projects' ./.ddev (not totally trivial to prevent overwriting)
• A ddev recipe command that would just wrap around composer. Usage example: ddev recipe req vendor/ddev-solr

Ping me if you think that's interesting. If I find time I might build that for my org anyways.

[rfay]

The idea here though is these recipes must be curated and tested... not sure that fits with your idea.

[tyler36]

To consolidate from elsewhere, the idea is to go with bats-core for testing.

[rfay]

Here's what I'm thinking about for this:

1. Bring service recipes into the ddev repo one at a time, starting with the ones that are already there (solr, beanstalkd, memcached). Then move on to bringing ddev-contrib services in.
2. Add a test that's more significant for each new service. I think we should use bats for the tests, it's just bash, people don't have to learn golang or anything.
3. Add a ddev service command with subcommands ddev service install <service>, ddev service uninstall <service>, ddev service enable <service>, ddev service disable <service>, ddev service list showing active, disabled, and available services.
4. Add testing using github actions as a separate test run - can just use linux at this point I think. Every push to ddev will run tests against the services, and also add a nightly.
5. Each service should have an owners section. In a perfect world test failures would notify, but it's probably good enough to just be able to ping the owner(s) of a service when things go south.

Issues:

• There are some services that require changes to the docker-compose file. That will have to be sorted out somehow.
• There are services that require extra files, etc.

[rfay]

More thinking:

1. Separate repositories for each recipe. That way they can be tagged. And people can just open their own and maintain them.
2. Official repositories for official recipes. With tests.