Hook system overhaul: Access any service, support other commands, user-defined hooks

[rfay]

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

There are a number of oversights in our hook system and fixing them up would make a lot of people happy even if it disrupted their workflow a bit:

• Allow access to any container/service. For example, one should be able to execute an exec hook on the db container, or on an arbitrary npm service. (Allow specifying target container for hook execution #1038)
• Allow other post-xxx hooks (like post-composer) (Provide hooks for other commands #1071)
• Consider allowing user-defined hooks. (Allow Users to Create and Trigger Arbitrary Hooks #638)
• Allow custom commands, perhaps based on hooks.
• Add composer to hook commands #1321
• post hooks like snapshot, snapshot-restore, pre-ssh? #1071
• Consider arbitrary commands, and perhaps thus pre and post hooks for those commands #638
• Allow users to create and trigger arbitrary hooks also relates to this.

[wizonesolutions]

I'm using post-start to kick off a Docker container on the host. It's a headless Chrome container; it's hard to get working within DDEV for now because it expects pages loaded through it to be requested by IP or localhost, and DDEV internal IPs are not stable, but the host.docker.internal IP is.

I run it -d --rm and would like to kill it "pre-rm" (which would also remove it), but there's no hook for that.

The hook would just be in config.yaml like now. My start one looks like:

hooks:
  post-start:
  - exec: touch ./-
  - exec-host: /bin/sh run-behat-requirements.sh

So I'd expect it to become:

hooks:
  post-start:
  - exec: touch ./-
  - exec-host: /bin/sh run-behat-requirements.sh
  pre-rm: # or maybe pre-stop if the other PR gets merged
  - exec-host: docker kill ddev-fps-chromeheadless

[rfay]

#1038 is more specific, about specifying target container for hook execution.

[rfay]

Overall there are so many things that can be done here:

• exec task must be able to target container
• User-defined commands that could be executed with ddev <command>, perhaps with or without arguments.
• pre- and post- hooks for all commands, including user-defined commands
• "Tasks" are currently "exec" and "exec-host". Could they be also any ddev command?

[cferthorney]

This has been discussed in Drupal Slack. I have summarised my thoughts below due to the 10K message limit on Slack.

I would like to be able to run custom scripts using (For example) ddev {script name} or ddev exec {script name} (at worst). This would mirror functionality already present in Docksal's custom commands which use bash. Docksal also has the concept of addons, which are centrally submitted scripts such as the phpunit addon by Oliver Davies. There is also Lando's custom tooling which puts commands in the yml. Specific examples of custom commands I have used/written for Docksal include:

• dev-reset (A reset script I wrote to truncate the database, import configuration from the config/sync directory to completely reset the database for migration testing)
• truncate-watchdog (Runs drush sql:query 'TRUNCATE watchdog;' to speed up finding specific errors)
• core-test-setup (Runs the necessary scripting to execute the core PHPUnit test suite without needing to ddev ssh into the cli container).
• compile-css (Lint and compile CSS ready for production use as opposed to development, or vice versa)

With regards to the possibility this type of functionality could use existing (or new) hooks; the above examples, I feel, do not fit well within (say) a post-startup hook as I may not always want to be able to run core tests, or may not always be migrating content. Some may also need running multiple times a coding session (Let alone a project sprint).

[rfay]

Thanks so much @cferthorney - that helps loads. I will try to take a look at docksal's approach and lando's custom tooling as well. But the specific examples really do help. Thanks!

[opdavies]

What @cferthorney said. 😆

[JustSteveKing]

I think what I would like to see here is a commands directory which is auto pulled into ddev? What this will allow us to do is configure and add commands much like we do with additional services in ddev, so we are sticking to an already defined pattern. Such as ddev phpunit would execute the ./.ddev/commands/command.phpunit.sh for example - an even better option would be to be able to dynamically check the operation script so that we could mix sh and php and even py files easily by following a convention .

[cferthorney]

I think what I would like to see here is a commands directory which is auto pulled into ddev? What this will allow us to do is configure and add commands much like we do with additional services in ddev, so we are sticking to an already defined pattern. Such as ddev phpunit would execute the ./.ddev/commands/command.phpunit.sh for example - an even better option would be to be able to dynamically check the operation script so that we could mix sh and php and even py files easily by following a convention .

This is effectively what Docksal do with the exception Docksal only uses Bash at present. I don't know if they have future plans to move to allowing other environments/languages. To my mind this would be perfect for Ddev, but I also realise I am slightly biased having used the docksal version extensively over the last 18 months to 2 years.

Also @rfay any script in the commands folder would have access to all the environment variables Ddev provides to/with Docker too. This way I could do something like drush uli --url=${VIRTUALHOST} --no-browser --uid=1 or something similar as a ddev command etc. I think any "command" option that doesn't provide access to ddev's own env. variables is going to be very limited.

[rfay]

The remaining work here is custom commands.