ddev / ddev-platformsh

Add integration with Platform.sh hosting service
Apache License 2.0
9 stars 10 forks source link

Don't run build and deploy hooks on every start #61

Closed aimfeld closed 1 year ago

aimfeld commented 1 year ago

The plugin creates post-start commands to run the platform.sh build and deploy hooks. These commands are run on every ddev start. However, I only want to run the build and deploy hooks when I first install the project, not every time I start the project.

I'm migrating from lando, where we had lando rebuild (runs the hooks) vs lando start (only starts containers). Can you point me to any resources how to achieve the same separation with DDEV?

This is the hooks section created by the plugin:

hooks:
  post-start:
    - exec: platform self:update -qy --no-major || true
    - exec: '[ ! -z "${PLATFORMSH_CLI_TOKEN:-}" ] && (platform ssh-cert:load  -y || true)'
    - composer: install
    # platformsh build hooks
    - exec: |
        bin/build-hook
    # platformsh deploy hooks
    - exec: |
        bin/deploy-hook
rfay commented 1 year ago

Thanks for opening this issue. DDEV doesn't have any concept of build vs start, but there's no reason we can't add a signal file or something that says "build already ran". It will be a good improvement.

aimfeld commented 1 year ago

In that case, I'll replace the post-start commands with a rebuild script, which I'll run when needed. That should solve the problem.

ptmkenny commented 1 year ago

Having also come from lando, I miss having the build vs. start distinction.

In my build step, there are some really slow processes (transpiling a JS webapp, for example), so I ended up adding a check in the bash build script to just skip certain steps if on ddev:

if [ x"$IS_DDEV_ENV" == "x" ]; then

I also needed to do this when using the n package manager to manage node versions; the nvm approach works fine with ddev, but n fails with command not found.

As my build script got more complicated with platformsh vs ddev steps, I realized it would probably be easier to maintain two separate scripts, one for platformsh and one for ddev. If I take that approach, I don't need the auto-run of the build/deploy hooks at all, but I would like to use the other features of this addon like the platform variables, so it would be nice to have a way to disable running the hooks. (hooks on by default, but can be disabled in cases like mine where the script is complicated enough to warrant a separate rebuild script). For now, I'm just detecting ddev in the build/deploy scripts and then exiting.

rfay commented 1 year ago

I think your nvm stuff should work ok with DDEV v1.21.5-alpha1 FYI.

The contradiction for some projects is that DDEV has most or all of the stuff "built in" that the platform scripts go out of their way to install, so all the installs that some projects do are wasted. So your approach is probably fine. But then... do you need this add-on at all?

rfay commented 1 year ago

I don't think this request is possible, since we don't necessarily know what the Platform build and deploy hooks do.

If they add a Debian package, for example, or make any other change outside the project context (like adding something to /usr/local/bin or the home directory), it's all lost on next restart.

If they do something like a node install, it's fine, because that affects the project itself.

Closing unless somebody has an idea how this would be possible. Happy to continue the conversation, happy to hear new ideas.

rfay commented 1 year ago

I should note that if you want to just solve this problem with DDEV, there are lots of options... you can have your custom post-start hooks only run when they need to, but better, you can put things that affect the docker image in the .dde/web-build/Dockerfile, etc.

But I don't think DDEV can guess what the impact of the various Platform hooks will be. That's the problem here.

ptmkenny commented 1 year ago

What about controlling whether the hooks run with an environment variable?

This doesn't provide the start/rebuild distinction asked for by the OP directly, but it does provide an easier way to code one yourself (by default, the hooks would be enabled, so after running processing for the first time, set the variable to disable the hooks in a file).

This also allows for "unbundling" the addon, which is the use case I had-- I want to use the platform environment variables provided by the addon, but I don't want to use the hooks.

In general, I think it would be great if addons would provide solid defaults (which they do already-- awesome) but also have an easy way to disable features individually.

rfay commented 1 year ago

@ptmkenny you know you can just remove the hooks from config.platformsh.yaml right?

rfay commented 1 year ago

It would certainly be possible to control the build hooks with an environment variable or with a file flag, absolutely. But "build" in Platform can affect both the repo (code) and the image (everything else, like packages). Things that "build" does to the repo would be fine and would work out great. But whatever it did to homedir or anything else wouldn't be there after ddev restart.

ptmkenny commented 1 year ago

Although the hooks can be removed in config.platformsh.yaml, that means I have to remove ddev-generated, which then means I have to apply future updates myself, right?

To me, it would be ideal if the various features provided by the addon were decoupled so that you could pick and choose what you wanted.

For example, by default, the addon provides:

And what I am suggesting is it would be nice to have an option that allows the user to say, "give me the environmental variables, but not the hooks."

rfay commented 1 year ago

DDEV doesn't know what parts of the hooks provide the environment variables :) But the environment variables definitely come from the hooks (unless specified in .environment, as some templates do it)