search

documentcloud / jammit

Industrial Strength Asset Packaging for Rails
http://documentcloud.github.com/jammit/
MIT License
1.16k stars 197 forks source link

S3 Feature Request #47

Closed bradrobertson closed 14 years ago

bradrobertson commented 14 years ago

I'm looking for an asset packager that would work with a read-only file system like Heroku. From what I can see, the only way to achieve this would be to upload the packaged files to a service like S3 and serve them from there. Any thought about adding this? I think it would make this plugin wildly popular for anyone using Heroku as there aren't many (or any that i know of) asset packagers that comply with the read-only fs.

jashkenas commented 14 years ago

Hi Brad.

It actually shouldn't be too hard to use Jammit with Heroku -- and perhaps we should add a section to the documentation about how to do it ... if you'd like to help with authoring that paragraph, it would be appreciated.

The gist is that you can just pre-build all your asset packages before you're going to release a new version, and then deploy them to Heroku along with the rest of your code. With Jammit, this should be as simple as running:

jammit

In your Rails root folder. (Use the --base-url option if you're serving MHTML). Deploy public/assets and you should be good to go.

Leaving this ticket open for discussion and specific requests for improvement. If anyone else has Heroku experience, it would be great to hear about it.

bradrobertson commented 14 years ago

ya I thought about this and should have mentioned that in my post. Heroku also uses a git deploy. so after doing the packaging, I'd then have to add these files into the repo in order for them to be pushed, which is less than desirable.

I suppose it's not the end of the world to have my packaged assets checked in, assuming that the jammit command overwrites these each time.

jashkenas commented 14 years ago

It is, but that's the way that Heroku recommends doing it, no?

http://groups.google.com/group/heroku/browse_thread/thread/718f7ced86aee5f6/c9e2e76a6ca37a44

Serving static files from S3 is going to be slower than serving them from a real webserver. (A real CDN would be a different story). I agree that adding them to your repo is less than desirable, but a read-only filesystem is also less than desirable.

What do you think of a scheme where you run Jammit in development as usual, but build and commit the assets whenever you tag and deploy a point release? Even if you have a real filesystem, you generally want to prebuild the assets, rather than having them lazily-generated after a deploy -- which results in a handful of initial slow requests.

bradrobertson commented 14 years ago

ya that's what i'm thinking now, and these committed assets don't need to make their way back to the origin/master or anything so it's not actually that big a deal. I'll close this then as I think we've found the best solution. When I get a chance to test it all out I'd be happy to post something in the docs on the matter.