Add command to restart node after the build

[apfelbox]

Hi,

right now the Next.js process starts with the outdated build and will fail in production (like not being able to load the assets).
That is why you need to restart Next.js at the end of the deployment once.

[apfelbox]

The whole handle_mounts script can be updated to just a few way simpler lines in the hooks. Also you should add a separate mount for the next image cache, that is then linked into .next/, so that you don't wipe your generated images cache after every deployment (as regenerating the images is really CPU intensive).

Would you be open for a PR restructuring it a bit?

[achton]

@apfelbox Is this a better way to restart than what is in #82 ?

Regarding the handle_mounts.sh script, we have found the same issue, but for .next/cache/fetch-cache. I am contemplating separate mounts as you outline. Do you have a suggested approach or example?

Also, I don't think PSH follows these repos, so it may be better to just share our solutions here 😶

[apfelbox]

@achton, yes this case is much better than #82, because the other one has a race condition:

Platform.sh starts up Next.js and then runs the deploy hook. However, Next.js has a bootup time and doesn't immediately listen to the port (depending on your application this is shorter or longer), so you might run into a case where lsof -t -i:$PORT just returns nothing, as Next.js is not up yet.

We had this case very reliably in one of our applications. Using systemctl is way more robust, as it works in any case.
Also directly using systemctl might make it in general marginally safer and faster, as it doesn't have to detect that the process was killed.

On your mounts question, we always have this setup, which is basically just the inlined calls. They are small enough:

mounts:
    '/.next':
        source: local
        source_path: 'next'
    '/.next-image-cache':
        source: local
        source_path: 'next-image-cache'

And then

build: |
    # ...

    # Keep build files out of reach
    mkdir -p .build/.next
    mv .next/* .build/.next

deploy: |
    set -x -e

    # Move stored files back
    rm -rf .next/*
    cp -r .build/.next/* .next

    # relink image cache dir
    rm -f .next/cache/images
    ln -s ../../.next-image-cache .next/cache/images

    # restart node
    systemctl --user restart app

The deploy hook is actually exactly the same as in all of our applications.
This setup is pretty simpel and works really well for us.

If you need to add more caches (like the fetch cache), you might need to adapt either the mount or add some more. In our case & architecture it's fine to start with a clean slate when deploying, but YMMV.

[achton]

@apfelbox Thanks for your input. we also did not use the lsof-based approach, but did this: kill -15 $(pgrep next-server | head -n1) .. in the post-deploy hook. 😂
Will give your approach a go.

We have also ditched the handle_mounts.sh script and symlink the relevant .next/cache subfolders as per your suggestion, thanks 👍🏻

[pjcdawkins]

@apfelbox @achton I've made another proposal in #733 , I'd appreciate your feedback there if possible!

One thing I'm not sure about is whether we should handle .next/cache separately, or if what I'm doing with .next is enough.