Ddev: Allow Users to Create and Trigger Arbitrary Hooks

[rickmanelius]

What happened (or feature request):

Feature Request

What you expected to happen:

• End-users have been using our pre/post hook functionality (documented here https://ddev.readthedocs.io/en/latest/users/extending-commands/)
• Additional use cases are popping up where end-users wish to trigger a predetermined series of commands that are not specifically tied to an existing DDEV event like starting the containers OR importing a database.
• It would be ideal to allow for additional entries that could be invoked stand-alone, such as an installation profile (see #5) or for triggering a series of unit or integration tests.
• A sample command might be something like ddev hook insert-task-key where "insert-task-key" would be stored in .ddev/config.yml under the "hooks" key.

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

3

[tmotyl]

1. The other approach would be to allow to extend ddev commands pool, or to create aliases for complex ddev exec.

Our use case is e.g. to be able to easily run tests (unit/functional...) in the container.
right now I need to call:

ddev exec ./bin/phpunit -d memory_limit=1G -c vendor/typo3/testing-framework/Resources/Core/Build/UnitTests.xml

and I would love to be able to shorten that to:

ddev exec unitTests

or sth similar.

1. Yet another solution would be to allow creating custom shell aliases from configuration, this way the command would be available in both ssh console (ddev ssh) or ddev exec <alias>

I've tried to work it around to create a script in post-start hook to make the custom command available, but the file was not created. My hook was:

hooks:
  post-start:
    - exec: "echo '#! /bin/bash'    >> /var/www/html/bin/unitTests"
    - exec: "echo 'bin/phpunit -d memory_limit=1G -c vendor/typo3/testing-framework/Resources/Core/Build/UnitTests.xml' >> /var/www/html/bin/unitTests"

[kaystrobach]

just to provide an idea how we would might use it:

commands:
    gerritStart:
      - exec-host: "ddev run gerritConfig"
      - exec-host: "ddev run gerritCommitMesssageHook"
      - exec-host: "ddev run gerritPreCommitHook"
      - exec-host: "ddev run gerritReset"

    gerritConfig:
      - exec-host: "git config user.name \"Your Name\""
      - exec-host: "git config user.email \"[email protected]\""

    gerritCommitMesssageHook:
      - exec-host: "mkdir .git/hooks"
      - exec-host: "cp Build/git-hooks/commit-msg .git/hooks/commit-msg"
      - exec-host: "chmod +x .git/hooks/commit-msg"

    gerritPreCommitHook:
      - exec-host: "mkdir .git/hooks"
      - exec-host: "cp Build/git-hooks/unix+mac/pre-commit .git/hooks/"
      - exec-host: "chmod +x .git/hooks/pre-commit"

    gerritReset:
      - exec-host: "git reset --hard origin/master"
      - exec-host: "git pull"

    validateRst:
      - exec: "Build/Scripts/validateRstFiles.php"

    unitTests:
      - exec: "bin/phpunit -c vendor/typo3/testing-framework/Resources/Core/Build/UnitTests.xml"

    functionalTest:
      - exec: "export typo3DatabaseName=\"func\" typo3DatabaseUsername=\"db\" typo3DatabasePassword=\"db\" typo3DatabaseHost=\"localhost\" typo3InstallToolPassword=\"klaus\" && bin/phpunit -c vendor/typo3/testing-framework/Resources/Core/Build/FunctionalTests.xml"

    # enableXdebug:
    # disabledXdebug:
    # https://docs.typo3.org/typo3cms/ContributionWorkflowGuide/DebuggingTypo3/Index.html

    openGerrit:
      - exec-host: "open https://review.typo3.org"

    openContribGuide:
      - exec-host: "open https://docs.typo3.org/typo3cms/ContributionWorkflowGuide/"

This would make it very easy for developers to onboard, as very common tasks are abstracted into a very transparent way

[rfay]

I don't think you'd want to run ddev inside an exec-host, but just to mention here as in Slack: Some of these things are easily done by adding scripts in the repo. So in a scripts directory for example, a gitsetup.sh script could do your git setup, and you could have exec: scripts/gitsetup.sh

[kaystrobach]

the idea was to provide an consistent entry point for devs ... so maybe i will stick with composer scripts for now ... but this feels weird too ...

[kaystrobach]

thought this was the goal of the project, if I'm on the wrong track please tell me.

[rickmanelius]

This is a big topic and related to customer requests on our hosting product. Tagging "needs decision" because there are likely other considerations that need to be addressed as well.

[kaystrobach]

currently we changed it to integrate it into composer.json ... so it might be not important anymore (atleast for TYPO3)

[codemonkey1988]

We are currently running into the same problem. We have some commands that needs to run in a container for our frontend developers. Especially webpack or linting commands. Our frontend developers are not experienced with command line, so we want to provide simple commands for them.

Currently, we put all the necessary commands in a readme file so that they can copy&paste the commands. We do not want to create a separate shell script for the commands, because we want to support the major platforms because of freelancers. To do so, we would have to create a shell and batch file and keep them in sync.

So it would be nice to define custom commands inside ddev config to improve working with ddev for people, that are not experienced with command line. They need to focus on their work and not learning what containers the project provides and what options the exec command has and also what's the document root inside the container.

[rfay]

Just an FYI here, if you need to use shell builtins (like environment variable setting, 'cd', 'echo', '&&', '||', shell redirection, and any other shell builtin that is not an actual command that can be found with which, then you can actually run bash. So ddev exec bash -c "NOTHING=something echo 1; somecmd.sh && someother.sh"

Examples in https://stackoverflow.com/questions/50971602/how-can-i-use-bash-constructs-like-cd-or-with-ddev-exec

[mfrieling]

@rfay about
commands: gerritStart: - exec-host: "ddev run gerritConfig" - exec-host: "ddev run gerritCommitMesssageHook" - exec-host: "ddev run gerritPreCommitHook" - exec-host: "ddev run gerritReset"

I agree that running ddev inside an exec-host is not good. But in some cases this example might make sense. What about a ddev-host command which eventually can only be run inside an exec-host hook and is aware of that context? With that it might be possible to provide some dynamic environment variables extracted from host information into the containers before they are started as well. That for example would make my setup we discussed much easier where m pre-start host script writes the extracted information in some files inside the .ddev folder which then can be accessed and applied by the pre-start exec script inside the container. I would not even need a exec hook then because I could use getenv() function from PHP directly.

[rfay]

It looks to me like custom commands have met the needs expressed here, people use them extensively.

Also, there are now pre/post hooks for many, many things.

Closing, happy to continue the conversation or reopen if I've missed the point.