After each deploy with Deployer it takes about a day to update the website on production

[formal thorn]

What I want:
For my deployment to take less time to update the newly released folder.

Steps

• Setup deploy.php and gitlab-ci (works) for Gitlab

• Using https://github.com/deployphp/deployer/blob/master/recipe/laravel.php with my own tweaks to it

• Pushing changes to main

• Job is running

• Job completed

• Folder structure on my server's website root now:
  /shared
  /current -> (latest version_number symlink)
  /releases/(latest version_number)

• Website path is: /path/to/website/current/public

What is happening"
After a successfull deployment, the deployer generates a new release and symlinks the current folder to that new release.
For example: /current -> /releases/10
All the other versions, from /releases/1 to /releases/9 are still there. But due to the website calling current, which is always symlinked to the latest release this should awork.

I expect it to take a minute or 2 to update... but how wrong I am. It now takes around a full day.
Before you ask yes I did do:
php artisan optimize:clear (if that's the correct thing to do) and I also tried doing them seperately on the current folder and latest release folder

I also added a command to laravel which is opcache:clear:

<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;

class ClearOpcache extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'opcache:clear';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Clear the PHP OPcache';

    /**
     * Execute the console command.
     */
    public function handle()
    {
        if (function_exists('opcache_reset')) {
            opcache_reset();
            $this->info('OPcache cleared!');
        } else {
            $this->error('OPcache is not enabled.');
        }
    }
}

And added this to my deploy.php, which shows 'OPcache cleared!' in the job that's running.

This doesn't seem to change it....

Does anyone know how to resolve this? And if so, please explain me how to because my caching knowledge is really bad....

[dusk saddle]

You might want to apply this approach; https://deployer.org/docs/7.x/avoid-php-fpm-reloading#fix-for-nginx
Sounds like the symlink is cached, so the old symlink is still used, this would normally require a PHP-FPM restart, or adjusting your nginx config to follow the real path

[formal thorn]

Thanks for your reply, however, when I do ls -lah I see that the current is correctly linked to the latest version. But maybe not in the cache/backend? Is that what you're saying?

[dusk saddle]

It would be cached in the FPM process (or nginx, dunno the exact details). The CLI is a different process, so yeah, it wouldn't be cached there.

[formal thorn]

I am using a pretty strict hosting provided, do you know an easy way to know what server is running? (apache, nginx, etc.)

I'm also very unfamiliar with this side of the backend, so sorry if I say dumb questions.

[dusk saddle]

I pretty much avoid shared hosting at all costs, as it just gives more burdens than it solves, so I wouldn't know. All I know is, you'd want to change that nginx setting.

Or restart FPM on every deploy

[formal thorn]

I'm not quite understanding the process of this.

Where would I paste this?

location ~ \.php$ {
  include fastcgi_params;
  fastcgi_pass unix:/var/run/php/php-fpm.sock;
- fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
+ fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
}

For nginx

[dusk saddle]

In the nginx config

[formal thorn]

On the server? I have no clue where that is lmao.

[dusk saddle]

Yes, on the server

[formal thorn]

I am not even sure if it's using nginx... shared hosts are quite something haha.
I am using combell

it's belgian

[dusk saddle]

https://nginx.org/en/docs/beginners_guide.html

By default, the configuration file is named nginx.conf and placed in the directory /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx.

[dusk saddle]

Yeah, a shared host usually doesn't even allow you to change these configs

[formal thorn]

Nope

So I don't think this issue can be resolved unfortunately.

Unless there is another way to fix this?

[dusk saddle]

The alternative would be restarting PHP-FPM on each release, but you likely don't have access to that either.
Same with clearing opcache; since it's a shared host it probably doesn't affect anything, as there are multiple sites on that server and using the same php process, so if anyone could clear the cache at any point it would negatively impact other sites.

[formal thorn]

PHP-FPM does not seem to be installed unless I am wrong.

[dusk saddle]

On a shared server you usually don't have access to that, as it would require root access

[formal thorn]

I'd probably be better off using another hosting provider like forge then?

[dusk saddle]

Forge doesn't do hosting. Forge does server management (and deploys, kinda)

[formal thorn]

Do you know a good hosting that allows better control?

So I can setup a Laravel project with deploys and configure to my liking

[dusk saddle]

You could just go for a VPS and use Deployer to provision that server

[formal thorn]

Alright thanks for the help and time. I really wished I could do something about it on the shared hosting cuz it works fine for other things....
I'll just have to deal with the waiting 1 day for now until the cache is expired by itself lol.

Because I'm not the best at setting up hosts and all

[dusk saddle]

Laravel Cloud might be something to look into once it releases. Or, as you mentioned, Forge. But that would cost Forge + the costs of the server(s) you set up. It's a fixed cost tho, so that's nice

[formal thorn]

Laravel cloud sounds interesting

Is that hosting/deployment in one without having to mess around?

[dusk saddle]

Ye, known as PaaS. You'd pay for what you use

[formal thorn]

Huge thanks for the help and time.

If anyone else has an idea of what might possibly resolve this issue, please let me know. Cuz if I can fix it here, then I will.

[formal thorn]

@dusk saddle
Quick update, I managed to fix it. I limited the amount of releases to 2/3, reducing any delay, I removed all old releases from 1 to 13, must've been something in my older version that caused it maybe. Tested a new deploy, instantly fixed.