I am running rails 3.0.1, and while we intend to move to 3.1 and the asset pipeline I am looking for solutions/workarounds for asset generation during unicorn hot restarts.
Essentially what happens currently is we deploy to our site and when the deploy is complete the "current" symlink is changed to the new directory which does not have the static assets yet. Then approximately 60 seconds later all assets are generated and all is well, but for the 60 seconds before the assets are generated our site is basically down.
Questions:
If I copy the files from the old release dir, to the new dir will the asset generation overwrite the older files I've copied?
Where in the rails code is the asset generation done? ActionPack Dispatcher?
Is the generation of these assets done upon initialization of the app or at another stage?
If you layout is something like this:
/srv/yourapplication/current
You should have a shared folder
/srv/yourapplication/shared/assets
and symlink public/assets to /srv/yourapplication/shared/assets
This way each time your old assets and new assets will all be in the same folder and will be served properly.
Related
I store user uploaded images inside /assets directory, so I serve them using require() which takes an uploaded image built inside _nuxt directory.
Now these uploads can be uploaded by users through the form and in production after every upload made I need to build them manually through the command line since the assets are not built on changes as it is in development.
Is there a sollution to build certain assets (uploaded images) after changes are made in production?
I'm doing some work on a RoR application that gets deployed as a war file using warbler. Prior to my involvement, the few images in the app were in the asset pipeline, but my role is to introduce slippy maps and homegrown map tiles.
Because the tiles take up a lot of space, and because they won't change anywhere near as often as the app, the idea was to simply serve them from public/images/tiles. The war file for the rest of the app would be deployed, then the tiles would be untarred into the proper directory.
This works fine in development mode, but the warbler deployment uses a context path and the tiles get 404ed because they're found at /contextpath/images , not /images
I haven't worked in a jruby environment before and the rest of the team just so happens to be out on vacation this week (ha!). Nick Sieger's recommendation about using config.action_controller.asset_host at Warbler: Where are my images wrecks the images and css that do work via assets, so I'd be grateful for any other suggestions that allow assets and public to coexist.
In production.rb try this line config.assets.precompile += %w( *.js *.scss *.coffee *.css ) then run jruby -S rake assets:precompile.
It will compile all you assets to static assets and warbler will then package them accordingly, it should solve your problem.
Another thing you can check is how you are pointing to the images in the Views. if you want them to be found in /image you should write the path as <%= image_tag "\image" %>. Regard the trailing \.
I'm in the process of upgrading a 3.0 Rails App to 3.1.4 including the Asset Pipeline.
I'm on Heroku, so I'm I have this in my application.rb
config.assets.initialize_on_precompile = false
I noticed that when I run:
bundle exec rake assets:precompile
it creates files in a public/assets directory (even though my assets are in app/assets already).
For example, it creates files like application-72b2779565ba79101724d7356ce7d2ee, as well as replicating the images I have in app/assets.
My questions are:
(1) should be uploading these files to my production server?
(2) if I'm suppose to be uploading these, am I suppose to update each application-xxxxxxxx or only the latest one?
To your first question: Heroku will not allow you to modify the filesystem. So your assertion is correct- You will need to pre-compile the asset pipeline before you send it up to Heroku, so that it can be utilized in your production environment.
And the latter: You'll want to make sure you have the latest compilation. Any others wont be used. The "xxxxxxx" portion is to make sure that your users have the latest and greatest version of your assets. It's a way of versioning what the browser gets, and making sure they're not caching a bad copy of the JavaScript, when you want to set up their cache to hold on to the JS and CSS files as long as they can, instead of constantly getting it from your web server.
Take my Heroku comments with a slight grain of salt, as I have not deployed to Heroku before. I just know how their system works to some degree.
Currently it seems Heroku is determined to pre-compile assets when I push my code up to my instances.
This is great for production servers, however for my "RAILS_ENV=development" server, this causes issues, as I now get pages with all the JavaScript files served up individually from my asset manifest, and then another file with the same code all grouped up as the pre-compiled asset.
This cause my jquery datatables libraries to break, throwing popup errors, which I don't get on my local environment (development or production) or in my production Heroku instance.
Is there anyway to disable pre-compilation of assets on Heroku for development mode instances ? Or is there any reason why these aren't already disabled on development Heroku servers already ?
If Heroku detect a public/assets/manifest.yml file then they will not attempt to precompile your assets and assume you are dealing with them yourself. More details at http://devcenter.heroku.com/articles/rails31_heroku_cedar
AFAIK, Heroku has to precompile assets to work around their readonly FS and the fact that the Rails asset pipeline wants to write files to the FS. The only thing I could suggest would be to work out why your assets are breaking when being compiled.
I worked around this by adding some voodoo to my Rakefile to disable the assets:precompile rake task.
first I add the user-env-compile labs component
heroku labs:enable user-env-compile
then add this to the beginning of my Rakefile
# found from http://blog.jayfields.com/2008/02/rake-task-overwriting.html
# used by conditional heroku asset compile magick
class Rake::Task
def overwrite(&block)
#actions.clear
enhance(&block)
end
end
Then I add this rake task in lib/tasks/disable_assets_on_heroku.rake
if ENV['RAILS_ENV'] == 'development'
namespace :assets do
task(:precompile).overwrite do
puts "Asset precompile skipped in #{ENV['RAILS_ENV']}"
end
end
end
Since I'm running my app on the Bamboo stack I'm precompiling my assets and committing them.
I've included the file manifest.yml in public/assets/ but heroku doesn't detect it. As a result it tries to compile assets and borks itself.
Am I missing something?
Ok, I discovered that I was trying to serve up unprocessed files from the public directory.
Also, I migrated my app to cedar which helped too. :)