lucasmotta
SSH deployments
Are you interested in enhancing this with SSH deployments? Basically everything's the same, but you can define some commands, i.e. set it up to pull, and then build and run with grunt (or whatever the user wanted to configure).
I'm probably going to create it in my fork anyway, but was wondering if you were interested in that, or just wanted to focus on S/FTP.
If you want you can implement this, go ahead - would be awesome. It should be a simple task, since I am already using the ssh2 library to handle the sftp scheme.
So maybe you can create a new SSH scheme, just extending the SFTP scheme and implementing the extra tasks that you need.
I haven't implemented SSH before because then you could easily use rsync to deploy your site. But it makes sense to cover most of the deployment methods inside DPLOY.
Indeedy, the basic premise was relatively simple, but there is one major flaw:
There is no post-push hook for git, and the post-commit hook doesn't work so well for syncing from a central repo.
So that one awesome feature goes out the window...
Otherwise, the premise is relatively simple. The one other thing is I'm having issues with ssh2's callback structure. Maybe I've just been in promise-land for too long, but I'm trying not to make it super complicated, haha.
Also, I love dploy that it works with very little setup and that it works with environments that don't support ssh access, etc, but this sort of setup does take a little more (gotta set up the repo on the remote server (which I guess is eventually a feature one could add)). But that being said, it would be great to have a workflow that always uses dploy, whether you have full ssh access (for me, that's preferred), you are able to use sftp, or even if you only have ftp access! So that's why I wanted to add this.
In general, I think a post-push would be preferable, if it were achievable. A post-commit opens the door to the server being up to date, but not the repo, and could cause a lot of problems if you have more than one person working on the project.
@CWSpear you could achieve this with the post-receive command, but it's executed only on the server-side.
Even thou I like the idea of having one simple command to execute multiple tasks (pulling from git, building, etc...), I would rather keep DPLOY responsible only for the deployment.
One thing that could be added is a pre-dploy and post-dploy parameters, where you can execute external scripts before/after each action. Something like this:
pre-dploy: node my-pre-dploy-task.js
But again, keeping those things outside DPLOY is preferable.
I think the pre/post-dploy params are a good idea, and maybe at least initially, the commit-message deploy won't work...? Obviously if you have your own server with your central repos, you could use post-receive, but it'd be nice if it would work with Git, BitBucket, etc.