Are you using {RELEASE} by any chance to run your commands in?

Yes, I do, but that's just giving the new release folder. Problem is that the preheat logic crawls the currently live site and that is still the "old" one at the time of executing the deployment script. So the preheated HTML files will be put into the currently live folder. If we could have the folders switched with a new custom variable, we could be sure to execute the preheating after symlinking to the new folder.

That would also give more flexibility to the zero downtime deployment script since this could be easily done with normal deployments because we control the actual "going live" ourselves on them via git pull, refresh caches etc. This "functionality" is missing on zero downtime deployments.

btw this does also apply to the queue restart problem. When you restart your queue during zero downtime deployment, it will not pick up the latest changes

Could you post your deploy script? (Exclude any sensitive data)

if [[ {COMMIT_MESSAGE} =~ "[BOT]" ]]; then echo "AUTO-COMMITTED ON PRODUCTION. NOTHING TO DEPLOY." {DO_NOT_NOTIFY} exit 0 fi

cd {RELEASE} git reset --hard git pull composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader {RELOAD_PHP_FPM}

rm -rf public/static/ php8.1 artisan cache:clear

php8.1 artisan config:cache php8.1 artisan route:cache php8.1 artisan view:cache php8.1 artisan event:cache

php8.1 artisan migrate --force

{RESTART_DAEMON ###}

php8.1 artisan statamic:stache:warm # Warm the Statamic stache. php8.1 artisan statamic:search:update --all # Update the search index. php8.1 artisan statamic:assets:generate-presets # Generate all asset presets.

yarn yarn production

echo "🚀 Application deployed!"

Anything that's relaying on currently live data (queues use currently active live directory, warm static caches with live URL) will not work with zero downtime deployment.

Constantly getting caught out with this myself.

I'm having issues with restarting queues / horizon when using zero downtime deploys. Would be nice to have a more like Envoyer approach where you're able to add a script that runs after symlinking the new folder.

Yeah, I'm having the same problem. The queue is still using the previously deployed code. Also, php artisan queue:restart does not results in a hard restart.

I will be working on a POC tonight which allows you to run commands after the symlink. This should solve a lot I supose.

@Ben would you be able to test?

@Dennis Did this change/prototype ever go live? I'm still having issues with queue:restart in a ZDT environment.