This repository is a template for providing DDEV add-ons and services.
In DDEV addons can be installed from the command line using the ddev get
command, for example, ddev get ddev/ddev-timescale-with-mongo-and-mysql-fdw
or ddev get ddev/ddev-drupal9-solr
.
A repository like this one is the way to get started. You can create a new repo from this one by clicking the template button in the top right corner of the page.
- The fundamental contents of the add-on service or other component. For example, in this template there is a docker-compose.timescale-with-mongo-and-mysql-fdw.yaml file.
- An install.yaml file that describes how to install the service or other component.
- A test suite in test.bats that makes sure the service continues to work as expected.
- Github actions setup so that the tests run automatically when you push to the repository.
-
Choose a good descriptive name for your add-on. It should probably start with "ddev-" and include the basic service or functionality. If it's particular to a specific CMS, perhaps
ddev-<CMS>-servicename
. -
Create the new template repository by using the template button.
-
Globally replace "timescale-with-mongo-and-mysql-fdw" with the name of your add-on.
-
Add the files that need to be added to a ddev project to the repository. For example, you might remove
docker-compose.timescale-with-mongo-and-mysql-fdw.yaml
with thedocker-compose.*.yaml
for your recipe. -
Update the install.yaml to give the necessary instructions for installing the add-on.
- The fundamental line is the
project_files
directive, a list of files to be copied from this repo into the project.ddev
directory. - You can optionally add files to the
global_files
directive as well, which will cause files to be placed in the global.ddev
directory,~/.ddev
. - Finally,
pre_install_commands
andpost_install_commands
are supported. These can use the host-side environment variables documented in ddev docs.
- The fundamental line is the
-
Update
tests/test.bats
to provide a reasonable test for your repository. Tests are triggered either by manually executingbats ./tests/test.bat
, automatically on every push to the repository, or periodically each night. Please make sure to attend to test failures when they happen. Others will be depending on you.bats
is a simple testing framework that just usesbash
. To run a Bats test locally, you have to install bats-core first. Then you download your add-on, and finally runbats ./tests/test.bats
within the root of the uncompressed directory. To learn more about Bats see the documentation. -
When everything is working, including the tests, you can push the repository to GitHub.
-
Create a release on GitHub.
-
Test manually with
ddev get <owner/repo>
. -
You can test PRs with
ddev get https://github.com/<user>/<repo>/tarball/<branch>
-
Update the README.md to describe the add-on, how to use it, and how to contribute. If there are any manual actions that have to be taken, please explain them. If it requires special configuration of the using project, please explain how to do those. Examples in ddev/ddev-drupal9-solr, ddev/ddev-memcached, and ddev/ddev-beanstalkd.
-
Add a good short description to your repo, and add the label "ddev-get". It will immediately be added to the list provided by
ddev get --list --all
. -
When it has matured you will hopefully want to have it become an "official" maintained add-on. Open an issue in the ddev queue for that.
Note that more advanced techniques are discussed in DDEV docs.
Contributed and maintained by @CONTRIBUTOR based on the original ddev-contrib recipe by @CONTRIBUTOR
**Originally Contributed by somebody in https://github.com/ddev/ddev-contrib/