Do you have any plans to sync?

[alexprey]

trafficstars

I have mixup of generated files localy, manually created and existing files on remote target where I deploy. Some times I generate the different set of files and it will be nice to delete older versions of that.

Example:

local

application/a-controller.php
application/c-controller.php
config/app.php
init.php

remote

application/a-controller.php (from first deploy)
application/b-controller.php (from first deploy)
config/app.php (from first deploy)
config/app.local.php (put manually)
init.php (from first deploy)
files/user-uploaded.png (produced by the code)
.htaccess (put manually)
verifier.xml (put manually)

Expected

DELETE application/b-controller.php
UPLOAD application/a-controller.php
UPLOAD application/c-controller.php
UPLOAD config/app.php
UPLOAD init.php

And keep all other files

It may require to introduce some remote state, but it will be nice to have this feature.

[simonh1000]

to be honest I have no plans for sync. With hosting slowly moving towards using git, that's your long term solution

[alexprey]

At the first time I use SSH with git checkout, but later I have artifacts that was need to build before deploying and it should be deployed at the same time. Also, some hostings don't support to use SSH + git to setup app :(

If I can introduce some sync solution, it can be included to the package or it out of scope of this package?

[der-On]

@alexprey Most hosting providers that have SSH support also support rsync, which is the preferred way when not limited to FTP.

[simonh1000]

@alexprey My feeling is that webhosting is moving away from FTP, and even from SFTP, towards technologies that have syncing by default. As a result I fear adding sync would be of limited benefit in all but the very short term.

I also not excited about leaving state on remote servers, but could be persuaded on that.

I don't want to be negative, but I'm worried about the maintenance costs for me of what would be quite a lot of new code, even if you had contributed it originally

[TomFreudenberg]

Hi @alexprey maybe you try this PR or fork - it is working pretty well for us. https://github.com/simonh1000/ftp-deploy/pull/117

[alexprey]

@simonh1000 ok, maybe you are right. So, I have one more question to clearify: the deleteRemote option respect the exclude values? If yes - that is a perfect

[TomFreudenberg]

Hi @alexprey

No, deleteRemote will (try to) recursively delete all files and directories on Remote.

Checkout function at: https://github.com/simonh1000/ftp-deploy/blob/master/src/lib.js#L114-L130

The exclude is just filtering the upload.

Maybe you try my fork (as long as @simonh1000 does not merge this PR 117 or give feedback) at https://github.com/TomFreudenberg/ftp-deploy

I guess it will handle the incremental update as you expect.

Cheers Tom

[alexprey]

Hi @TomFreudenberg, thanks for the answer. I'm already bookmark your solution, but not try to use it yet. I'm back with feedback later when setup it for my deploy process, thanks!

[TomFreudenberg]

@alexprey your welcome and as long as possible I may give some support.

Just as a note in front of your updates to the deploy process and your requirements from top of this issue:

I have mixup of generated files localy, manually created and existing files on remote target where I deploy.

Maybe you you need to schedule or initiate a run of folderHash on remote as well to get the minimum exchangeable files.

On our setup the files on remote side should be equal to what is in the "to distribute" path. Anything differs from that should be removed or updated.

If you like to leave files untouched remotely in general you maybe need to get some exclude improvements in addtiion.