Deployer: Problem with creating symlinks in `deploy:shared` task

[Serhii-DV]

| Q | A
| ----------------- | ---
| Issue Type | Bug
| Deployer Version | 4.0.1
| Local Machine OS | Ubuntu
| Remote Machine OS | CentOS

Description

Deployer doesn't create symlink for shared folders as expected.

Steps to reproduce

For example, I need to create and get next shared folders:

set('shared_dirs', ['system/config', 'system/logs']);

According to recipe/deploy/shared.php first it runs (see line 19):

cp -rn /var/www/html/xxx/_deploy/releases/11/system/config /var/www/html/xxx/_deploy/shared

This command creates a folder

/var/www/html/xxx/_deploy/shared/config

and copy all files from folder

/var/www/html/xxx/_deploy/releases/11/system/config

And then at line 29 it create symlinks:

ln -nfs /var/www/html/xxx/_deploy/shared/system/config /var/www/html/xxx/_deploy/releases/11/system/config

As you can see, it creates a symlink to shared/system/config folder. But, as I say before, it copies files to shared/config folder.

So. after task deploy:shared we have two folders:

releases/11/system/config >> shared/system/config // empty folder and symlink points to this folder
shared/config // folder with files and symlink doesn't point to this folder

But expected to have only one config folder:

releases/11/system/config >> shared/system/config

The same happens with system/logs.

[pdbreen]

I just looked more closely at my server after an upgrade from 3.x to 4.0.1 today and I can also confirm that extra directories are being created at root level within shared directory. With config of:

set('shared_dirs', [
    'storage/app',
    'storage/framework/cache',
    'storage/framework/sessions',
    'storage/framework/views',
    'storage/logs',
]);

I too end up with app, cache, sessions, views and logs directory created at root of shared. Fortunately, the shared/storage/* directories created by the earlier version were the ones still being linked into my releases so everything continues to work.

[pdbreen]

Looks like this commit is where the change was introduced from 3.x to 4.x:

https://github.com/deployphp/deployer/commit/18b9634e00b5027b647bf1fb9467f54806bdd841#diff-1272beae40bb3bcb456e54596a3bd2f0

Maybe @henriquebremenkanp can comment or review?

[henriquebremenkanp]

My PR was to fix a problem introduced on this commit
https://github.com/deployphp/deployer/commit/4238fb0c5d2871e66129b5a573619a0df504df94#diff-5f5153d8e49437a92b734ed44b5008deL12

The bug it introduced made deployer delete the entire storage folder, then created a new one, so new installations of Laravel would not work because the newly created storage was missing all it's subfolders and files. Possibly other applications that rely on the folder structure or files inside a shared folder would also fail. That said, my PR is to move the files without overwriting instead of deleting the cloned folder and creating new one.

Anyways, it looks like the problem is that storage gets linked to shared/storage which is fine, but cases like storage/app gets linked to shared/app instead of shared/storage/app which breaks the folder structure and may lead to naming conflicts too. I guess fixing it to shared/storage/app will make it work again for you, right?

Sorry about that.

[pdbreen]

Seems to me that we should back out the @oanhnn change to shared_dirs in the laravel specific recipe and then back out the change to the core deploy:shared task. But, not my call.

In any case, as @DyaGa pointed out, the problem with things as is is on the copy command - not the link command. The copy isn't retaining the directory structure within shared.

[henriquebremenkanp]

Please, can you check if this PR fixes the issue for you?
It should copy successfully if shared_dirs is set to the whole storage folder alone or set to multiple storage/app, storage/frameworks/cache subfolders one by one.

@elfet Can you take a look also?

[antonmedv]

Problem here is what cp expected to get only first level folders like set('shared_dirs', ['storage']);m but then it got set('shared_dirs', ['storage/app']); it works incorrectly. I know how to solve this.

[Serhii-DV]

@henriquebremenkanp, it seems that your PR is working. It can be used till the next bugfix release.