Add functionality to upload assets.

[arenoir]

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.

[Turbo87]

@arenoir any progress on this?

[arenoir]

Turbo87 not yet. I am unsure if scp is the way to go anyway. It works well for single files but not so much for recursive directories. I am thinking of placing assets in a version_id subfolder. So assets can be easily managed. I am open to ideas.

For now I am using the ember-cli-deploy-rsync addon for assets.

[lancedikson]

@arenoir, I think that placing assens in a version_id subfolder is a great idea. Do you have any progress for the task? I can help if you share your progress. It's very important thing for me.

[sandstrom]

Agree, assets support would be great. ⛵

The capistrano flow for something similar is to:

1. tar the files
2. sftp to host (https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol)
3. unpack and move into revision-keyed directory
4. symlink old release/revision to new release/revision

Another one would be support for multiple machines, i.e. an array of IP's to connect to (for upload), whilst only building once.

[miguelcobain]

@arenoir any reason in favor of ssh+tar instead of rsync?

Or is your reasoning that since all assets are fingerprinted we need to deploy them again anyway?
Rsync is nice because it uploads the difference.

[arenoir]

@miguelcobain Rsync makes sense when the assets are uploaded to a common assets directory. I am proposing keeping a folder of assets for each revision. The downside is each revision will certainly have duplicate assets but I feel the benefit of having a complete package of the the revision out ways that.

[arenoir]

The other disadvantage of versioned asset folders is the browser will have to recache assets that may not have really changed between deploys.

[sandstrom]

@arenoir if the fingerprint (and hence the filename) hasn't changed the browser won't re-cache even though the files may reside in multiple directories (multiple copies) on the server.

Multiple directories (plus symlink to target current) makes rolling back to a previous version easier.

[arenoir]

@sandstrom I am proposing referencing the assets by their versioned path.

The link to the asset would look like.

/revisions/{revisionId}/assets/application-{md5}.js

Even if the file name is the same I don't think the browser will cache it because the path will have changed between versions.

[sandstrom]

@arenoir I see, what you propose is one way of doing it.

Another one is something like this:

/revisions/{revisionId}/assets/application-{md5}.js # file
www.example.com/assets/application-{md5}.js # external path

Which one of these two would be entirely configurable, i.e. depend on webserver configuration.

[arenoir]

@sandstrom having the external path always resolve to the current revision directory would work but prevent previewing other revisions. So perhaps a config option not to change the asset paths is also needed.

Here is how I configured nginx to work with revisioned assets. https://gist.github.com/arenoir/ab00ef67f2b2838f78ea950675e1a8bf

[miguelcobain]

Idea: copy the assets folder from the previous revision and then rsync to that new directory?