I'm running
RAILS_ENV=staging bundle exec rake assets:precompile
on two different machines and get different fingerprints for the same asset files. I have Rails 4.0.2 installed on both machines. The machines are
Shouldn't the fingerprints be the same no matter on which machine the assets are compiled?
EDIT: The Linux machine is an EC2 instance. So I made an AMI of it and launched a second instance. Compiling the asset on this identical instance results in the same fingerprints as created on the original instance. It seems to be a 'problem' with my development machine.
The asset pipeline provides a framework to concatenate and minify or compress JavaScript and CSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB. Prior to Rails 3.1 these features were added through third-party Ruby libraries such as Jammit and Sprockets.
rake assets:clean removes compiled assets. It is run by cap deploy:assets:clean to remove compiled assets, generally from a remote server.
rails assets:precompile is the task that does the compilation (concatenation, minification, and preprocessing). When the task is run, Rails first looks at the files in the config.assets.precompile array. By default, this array includes application.js and application.css .
I found some additional info on a related post here that's probably more relevant regarding how checksums are calculated: How does finger print digest gets calculated in Rails 4.2
I'm also leaving my original answer below because I think it's still relevant:
I think this is behavior is working as designed. Sprockets may have changed since the time this question was asked, but I think this code comment might explain why:
# Caveat: Digests are cached by the path's current mtime. Its possible
# for a files contents to have changed and its mtime to have been
# negligently reset thus appearing as if the file hasn't changed on
# disk. Also, the mtime is only read to the nearest second. It's
# also possible the file was updated more than once in a given second.
On my macos System:
pry > File.mtime("Rakefile").to_i
=> 1605021933
On a remote Linux server, with the exact same file pushed up:
pry > File.mtime("Rakefile").to_i
=> 1606847789
In my case, I've noticed the mtime of my files get modified/updated locally (macos) for reasons that aren't clear to me. I think it's caused either by a vim plugin I'm using (fzf? an indexing tool? I haven't researched it)
If you do an MD5 on these two files they're identical though.
tldr; The assets may be identical, but the hash appears to include other information which could vary from system to system
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With