arenoir / ember-cli-deploy-ssh2 Goto Github PK

@arenoir I'm on a bad internet connection and it seems that the plugin isn't waiting for the tasks to finish. Haven't found the source of the problem but it looks like some of the methods don't return a promise causing ember-cli-deploy to not wait until the work is done. Are you still maintaining the plugin? I would dig into it and send a PR. I think that would solve #8 as well.

If assetsDestination present upload assets to specified destination.

• upload to assetDestination using tar and sftp Note assetDestination is relative to revision folder
• prepend revision + assetDestination to all asset references similar to how the fingerprint functionality of ember-cli works.

Note. instead of uploading all files one at a time and creating directories use tar.

The initial deployment works as expected, where you get a structure like:

root
  active (symlink to revisions/<hash-deployment-A>)
  revisions
    <hash-deployment-A>

However, subseqent calls to "activate" will create something like this (eg. wanting to activate a new deployment with <hash-deployment-B>):

root
  active (symlink to revisions/<hash-deployment-A>)
  revisions
    <hash-deployment-A>
      <hash-deployment-B>
    <hash-deployment-B>

So, as you can see, the active symlink doesn't change to revisions/<hash-deployment-B> as would be expected. Instead, there's a symlink <hash-deployment-B> that points to revisions/<hash-deployment-B> in the directory that is currently referenced by the active symlink.

This is because the simlink is created without the -n option, which ensures that the target path isn't resolved in case it's a symlink.

There are two possible solutions to this problem:

1. Simply delete the active symlink before re-creating it.
2. Use ln -fsn to create symlinks instead of just ln -fs

I suggest to use the second approach, as it's just a very minor change/fix.

The redis plugin's activate hook returns { revisionData: { activatedRevisionKey: '[the key]' } } which is great for notification plugins to use. It would most excellent if this plugin did the same thing.

• extract ssh client to separate class so it can be stubbed.
• add tests.

hi

maybe it's me, but i'm getting "Encrypted private key detected, but no passphrase given".

However I am able to ssh into my server with public key authentication just fine. Why does this plugin use my private key? And why does it have a passphrase? (I wouldn't even know anything other then '').
Can I specify a passphrase, if I have one?

Thanks

When my applicationFiles consists of:

['index.html', 'assets/gui.css', 'assets/gui.js', 'assets/vendor.css', 'assets/vendor.js']

But when I add 'font/material-design-icons/Material-Design-Icons.eot' to the list so it looks like:

applicationFiles: ['index.html', 'assets/gui.css', 'assets/gui.js', 'assets/vendor.css', 'assets/vendor.js', 'font/material-design-icons/Material-Design-Icons.eot'],

I get the following error:

- Uploading `applicationFiles` to /var/www/app/revisions/7c33053dff16862be49331bfc02ac39c
/Users/me/Projects/app/frontend/node_modules/ember-cli-deploy-ssh2/lib/ssh-client.js:121
            sftp.fastPut(src, dest, {}, function (err) {
                ^
TypeError: Cannot read property 'fastPut' of undefined

Copy method of activation doesn't work on some systems (busybox based, e.g. boot2docker/docker-machine), whose cp doesn't support -T parameter, the command then fails. I think the line 107 of index.js should just be:

linkCmd = 'cp -R ' + activeRevisionPath + ' ' + activationDestination;

Running ember deploy production --activate on Windows results in the following error.

node_modules\ember-cli-deploy-ssh2\lib\ssh-client.js:59
        var stream = sftp.createWriteStream(path);
                         ^

TypeError: Cannot read property 'createWriteStream' of undefined
    at E:\Code\proj\node_modules\ember-cli-deploy-ssh2\lib\ssh-client.js:59:26
    at E:\Code\proj\node_modules\ssh2\lib\client.js:840:14
    at SSH2Stream.onFailure (E:\Code\proj\node_modules\ssh2\lib\client.js:1177:5)
    at SSH2Stream.g (events.js:286:16)
    at emitOne (events.js:96:13)
    at SSH2Stream.emit (events.js:188:7)
    at Socket.<anonymous> (E:\Code\proj\node_modules\ssh2\lib\client.js:320:14)
    at emitOne (events.js:101:20)
    at Socket.emit (events.js:188:7)
    at TCP._handle.close [as _onclose] (net.js:493:12)

This seems to be caused by a race condition that causes the ssh client to be disconnected before the manifest upload happens. If I comment out the closing of the connection in teardown(), everything works as expected.