1

1) Why does an image that is known to have not changed ( a visa logo ) have 3 different versions on one server, and 4 different versions on another. These two servers are in different environments:

 ls -la public/a/visa-*
-rw-r--r-- 1 rails rails 1506 2012-03-04 06:33 public/a/visa-2c267b881e96647fbf8297637daf7132.gif
-rw-r--r-- 1 rails rails 1506 2012-01-14 02:33 public/a/visa-603d00ea229b0cb010f2cd1a0a486769.gif
-rw-r--r-- 1 rails rails 1506 2012-03-13 18:34 public/a/visa-fe533b87916500d8ab2ce4a72f45b942.gif

$ ls -la public/a/visa-*
-rw-r--r-- 1 rails rails 1506 2011-12-24 19:35 public/a/visa-4506288212ff5ef40a1af89abd829294.gif
-rw-r--r-- 1 rails rails 1506 2012-03-13 01:19 public/a/visa-4559e644c6dc9eccb35fc06cf3696bef.gif
-rw-r--r-- 1 rails rails 1506 2011-09-18 15:11 public/a/visa-873a9dddb6815e34ddc6049cfb3ec7d8.gif
-rw-r--r-- 1 rails rails 1506 2012-02-26 01:23 public/a/visa-9678ba047d426c775771509f364e8590.gif

... this pattern is true for every asset I have. I thought the idea was to have the filename be based on the contents of that file.

2) If the filename is based on the contents of the file, how does rails map <%= image_tag 'foo.png' %> to the assetified path that includes the hash?

3) If the filename is supposed to be based on the contents of the file, why am I 'precompiling' my assets every time I deploy DURING THE DEPLOY PROCESS -- It now takes 6 minutes compile assets on my app VMs. During my deploy. The rest of my deploy takes maybe 30 seconds. -- Why isn't the recommended pattern to compile your assets prior to deploy, check them into source control, and deploy?

jsharpe
  • 2,546
  • 3
  • 26
  • 42

1 Answers1

1

1) I think there was a bug in an early version of Sprockets that did this - which version of Rails (and Sprockets) are you using?

2) Rails maps the assets to hashed names based on a manifest.yml file that is generated at precompile time. Sprockets passes a hash of the mapping back to Rails, which saves it in public/assets. When Rails boots it loads this file into memory for fast access.

3) You can compile locally and commit. The only caveat is that you need to change the asset path prefix in development.rb to avoid serving these static asset in dev mode.

Richard Hulse
  • 10,383
  • 2
  • 33
  • 37
  • On point 3 (asset precompile performance), I can confirm that performance has improved significantly in recent versions of Rails (3.2+) -- this was a major pain in early versions. This is not to say it's _fast_ :-). See http://stackoverflow.com/questions/7537474/rake-assetsprecompile-is-slow – Tom Harrison Mar 13 '12 at 21:04
  • 1
    See my [blog post](http://richardhulse.blogspot.co.nz/2012/03/rails-how-to-compile-and-commit-assets.html) for details on avoiding the pitfalls of compiling locally. – Richard Hulse Mar 13 '12 at 23:45
  • I'm on 3.2.2. Pretty sure my gems are up to date too. I'm going to rm my assets on next deploy to verify #1. – jsharpe Mar 14 '12 at 01:30
  • 2/3 seem reasonable, i still dont see why the recommended pattern is to do all this during the deploy process... – jsharpe Mar 14 '12 at 01:31
  • I think the reason is 'no surprises'. It just works like magic, without having files in public/assets to commit. – Richard Hulse Mar 14 '12 at 03:40