Our Rails 3.2 application uses 4 different hosts as CDN. Upon deployment, we have a task that run assets:precompile on these 4 boxes. The problem we're facing is that the assets that are compiled have different fingerprints/digests. My understanding is that the fingerprints/digests are generated from the content of our assets file so they should be the same across different boxes. Does anyone know what the cause might be? Thanks,
I have dug around in the code and can't see why this is. They should be the same.
If you are deploying to 4 hosts you might want to consider precompiling locally - see this answer for details - as it is a lot faster.
Related
I am working with Rails 3.0.3 and Bluepill 0.0.51. I am trying to troubleshoot a situation where Bluepill is trying to start multiple instances of my ruby servers in some cases, but having trouble knowing where to start since the only files I have to look at are my ruby server .rb files and my .pill file in my rails app root folder. What are the configuration/other files that Bluepill creates on my system? Thanks so much in advance.
When you do run a successful pill recepie it can create different files based on your configuration. If you demonize the process it will create a .pid for each process that stores a value that represents the Process ID of that process so it can shut it down. It will also create a log file and sometimes files in sock. It uses /var/run/bluepill by default but if you run it in --no-privileged mode it will want you to specify the location, preferebly in your applications folder.
It doesn't create anything to configure but rather you configure everything in the pill file. It can be tricky getting everything to work but you have to keep trying. I realize this post is old so i hope your solved it :)
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.
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. :)
Rails 3.1 loads pages terribly slow in development. It's processing them through the pipeline, one at a time, and takes way too long.
Is it possible to precompile my assets (which I'm not testing right now, so static files are fine) and have Rails not be responsible for serving them? Would that make things faster?
Update: Got a solution.
Richard Hulse has the correct answer to this question. rake assets:precompile will prebuild assets so they are served directly, without the asset pipeline.
But Frexuz's answer solves the problem of slow loading I've been having. Loading the Rails-dev-tweaks gem makes page loading in development markedly faster.
I had the same problem! It could take from 2-4 seconds extra to load a page because of the assets.
Take a look here (a gem): Rails 3.1 is very slow in development-mode because of assets, what to do?
This made serving assets almost instant (server console says 1ms per asset), using the asset pipeline normally.
Yes.
You can run the precompile task (in 3.1.1) and it will just work - the precompile task will give you assets without fingerprints as well as with, which is what you need in development mode. (Fingerprints are not added in dev mode).
Beware that you don't commit these to source control though.
What is more of a concern is the slowness. I have 4 stylesheets and 15 javascript files in my manifests, and it is only a bit slow on the first request.
What do you see in your logs when the assets are accessed? You should be able to see them being compiled on the first hit and each subsequent request should be a 304 not modified.
Also, do your config settings for dev match those in the asset pipeline guide? If you were compressing in dev mode with lots of files, this could be a source of slowness.
symfony1.x followed a good standart that the whole framework lies somewhere outside and is available to any project. Today I started to read symfony2 documentation and actually downloaded the 'with vendors' 2.0.1 package which is presented on download page. After opening the package I was a bit surprised of what I've seen. But after looking around the package I found that the only folder I need is 'vendors' one - so I copied its content to my '...\lib\vendor\symfony2' folder (near '...\lib\vendor\symfony' and '...\lib\vendor\ext'). I added it to include path and proceed reading documentation. And then I found a problem - a command listed 'php app/console generate:bundle --namespace=Acme/HelloBundle --format=yml' produced simple questions. Did they miss to explain how to generate a project (structure, preconfiguration, command-line files, etc)? And what about '.bat' and '.sh' files?
Symfony2 is very, very different than symfony 1 - especially when it comes to the directory structure. You can't simply drop in the vendors dir and expect it to work. This page explains how to setup a new Symfony2 project.
I recommend you to forget Symfony... and to think with Symfony2 about another think completely different than S1.
Installation is really simple and you will need some advanced PHP knowledge just to understand how it works... But if you have worked with S1, I expect you will have not much problems :)