-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add functionality to upload assets. #4
Comments
@arenoir any progress on this? |
Turbo87 not yet. I am unsure if For now I am using the ember-cli-deploy-rsync addon for assets. |
@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. |
Agree, assets support would be great. ⛵ The capistrano flow for something similar is to:
Another one would be support for multiple machines, i.e. an array of IP's to connect to (for upload), whilst only building once. |
@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? |
@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. |
The other disadvantage of versioned asset folders is the browser will have to recache assets that may not have really changed between deploys. |
@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. |
@sandstrom I am proposing referencing the assets by their versioned path. The link to the asset would look like.
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. |
@arenoir I see, what you propose is one way of doing it. Another one is something like this:
Which one of these two would be entirely configurable, i.e. depend on webserver configuration. |
@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 |
Idea: copy the assets folder from the previous revision and then rsync to that new directory? |
I'm currently trying to figure out how to deploy assets using this plugin. Is there a way to also invoke the Ideally, everything would be deployed to the same revision… eg:
Is that possible currently? Can I somehow pass the revision-hash to the |
@bummzack : Did you find how to achieve this ? |
@bobbus Not really, I wrote my own deployment plugin (as in-repo addon) to achieve what I need. Other than using rsync to copy files, I also needed to create some custom symlinks, so the custom plugin was pretty much the only option. |
If
assetsDestination
present upload assets to specified destination.Note. instead of uploading all files one at a time and creating directories use
tar
.The text was updated successfully, but these errors were encountered: