ddev
ddev copied to clipboard
Add `--skip-hooks` flag for ddev start, restart, etc.
Is your feature request related to a problem? Please describe.
My goal is to always have my commands executed under DDEV. So for example I don't want to run composer install
, but instead ddev composer install
. To do so I need my project to be started.
However, I often have my config.local.yaml
defined with post-start
hook that will drush site-install
. So what happens is, on first install, it will start the container, try to install (and fail because composer didn't run yet), and then it will composer install
.
I was able to workaround it, with some trickery. Specifically:
ddev composer install
cp .ddev/config.local.yaml.example .ddev/config.local.yaml
ddev restart
Describe the solution you'd like
Instead of this late copy, or having to delete the config.local.yaml
, it could be convenient to do something like:
ddev start --skip-config-hooks
ddev composer install
# Restart, to run the post-start hooks.
ddev restart
Makes sense. We may be able to come up with a more elegant solution as we think about it. But I find hooks that execute when I don't need them annoying, so this might be a good path.
I would also love to have the possibility to skip the pre and post start hooks. 3 flags would be nice and cover all needs imho:
- --skip-hooks
- --skip-pre-hooks
- --skip-post-hooks
How about just --skip-hooks, global ? The more stuff we add, the harder it is for everybody to understand. And of course... people can just comment out the hooks.
@amitaibu The easier thing for what you're doing is to make the hook smart enough to do what's needed. For example, load a db if needed, run composer install if needed, etc. Like this one
Just thought about this and found this issue!
@rfay I think adding a global --skip-hooks
would be great.
I often manually disable the hooks to save time when I restart the project and know that the hooks don't need to run (especially when restoring a database snapshot).
Having the ability to skip hooks is something we would like to have.
In my situation we use "ddev import-db --src=db.sql" to import db BEFORE running 'ddev start -y'.
But we see from the logs that ddev import-db triggers the post-start hook and ends with error.
We need to run ddev import-db without triggering hooks.
Thanks
Of course, you can make your hooks less fragile. In your case @karpa you could check for existence of db before running hooks, as in https://github.com/drud/ddev-contrib/tree/master/hook-examples/import-db-if-empty
Thanks for pointing out the possible workaround @rfay! Actually we have made a similar workaround ourselves (based on our app configuration). But having the proposed solution of this issue would be better.
+1 for this feature. I could use this for disabling post-import-db hooks.
+1
I could use this very much.
We do sanitation after an ddev pull
.
But when syncing acceptance or pre-prod environments I have to comment out the sanitation step, what I always forget and later regret.
@rfay did you have a start-commit already somewhere? I want to contribute a start for the feature somewhere this weekend
@MakerTim I think the first thing to think about is whether you could make your hook less fragile. Could you test for whether it's already sanitized? Could you use an environment variable or something to control it? I'm afraid something like --skip-hooks
will still cause you trouble because you'll forget it just the same way.
And +1 for doing the sanitization!
Doing it upstream would be more robust and less prone to failure though...
+1 for global --skip-hooks
my use case would be to do an initial database import without our organization-wide default pre-import-db hook which executes a ddev snapshot:
ddev --skip-hooks import-db --file=db/dump.sql.gz
+1 for global --skip-hooks
+1 for global --skip-hooks
I now use yq
to remove the hooks temporary and after i set them back.
My usecase lately is to sync pre-production to production. and backwards when the customer wants to do a lot of changes at once. They do a content stop on production and do everything to a pre-production.
You might want to put the hooks in a config.hooks.yaml
and link/unlink the extra file.
My usecase lately is to sync pre-production to production. and backwards when the customer wants to do a lot of changes at once. They do a content stop on production and do everything to a pre-production.
I assume you're talking about some database processing you're doing, in which case you could make a smarter hook that respected an environment variable or whatever.