Open luckyraul opened 7 years ago
@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.
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.