mina

mina copied to clipboard

I've started to update our deploy script from 0.3 to 1.x and have noticed that now the current symlink use a global path. In 0.3 it was a relative.

It breaks FTP clients connection through the current folder.

@d4be4st ping

@luckyraul How does ftp relate to mina?

@stereodenis

Problem is not in the FTP, it is in the new way of creating symlink for the current folder

mina 0.3 use a relative path in the symlink for the current mina 1.0 use a absolute path in the symlink for the current

Ftp client in our case can't resolve absolute paths because of a chroot enviroment.

In my case, it hinders obtaining Let's Encrypt certificates for LXC containers. I could run:

certbot certonly --webroot -w /var/lib/lxc/container/rootfs/home/user/app/current/public -d example.com

But current doesn't work outside of a container. In other words, absolute symlinks doesn't work outside of any chroot.

What would you do about all other linked paths?

For example the stuff that ends up in shared folder? They can have multiple parent folders and we would need to do some "calculations" for them and it links would end up like: ../../shared/public/assets to work

Or are you only interested in current folder?

@x-yuri @luckyraul

If you are only interested in current folder there is an easy solution:

set :releases_path, -> { "releases" }

Override releases path. One caveat here is that you need to wrap all tasks that use fetch(:releases) path in in_path fetch(:deploy_do) do (in default mina only deploy:cleanup and rollback

in_path fetch(:deploy_to) do
  invoke :'deploy:cleanup'
end

I see no advantage to absolute symlinks over relative ones. I asked about it on Stack Overflow, but the best I could get is that absolute symlinks are easier to create. So I think it's best to switch to relative symlinks by default.