Cannot execute rake assets:precompile

[mtylty]

This is what I get when I try to compile the assets (even with capistrano 2.8.0)

$ rake assets:precompile
rake aborted!
rails_admin/aristo/images/ui-icons_222222_256x240.png isn't precompiled
(in {rvm_path}/bundler/gems/rails_admin-ee9ee06a7ae4/app/assets/stylesheets/rails_admin/aristo/jquery-ui-1.8.7.custom.css.erb)

Tasks: TOP => assets:precompile

[mtylty]

I almost forgot.... I'm using rails_admin ee9ee06 and rails-3.1 stable...

[gunn]

+1

[mtylty]

Seems that setting

config.assets.compile = true

fixes the problem...

[mtylty]

I've been digging through the rails source code... By looking at https://github.com/rails/rails/blob/v3.1.0/actionpack/lib/sprockets/helpers/rails_helper.rb
it seems that setting

config.assets.compile = true

is necessary if you want to lazily compile assets in production (since otherwise rails won't compile uncompiled stuff)...

On the other hand, from what I can see here:
https://github.com/rails/rails/blob/v3.1.0/actionpack/lib/sprockets/assets.rake
it seems that rake assets:precompile is a task meant to be executed in the production environment, which is
somewhat controversial to me.... (maybe the task should be meant to run in the development environment)

Could it be a rails bug?

[bbenezech]

I don't like where this is going... Env should be as agnostic as possible, just driven by a bunch of parameters in environnement/.rb and a couple of config/.yml files.

This smells really bad:

if ENV["RAILS_GROUPS"].to_s.empty? || ENV["RAILS_ENV"].to_s.empty?
  ENV["RAILS_GROUPS"] ||= "assets"
  ENV["RAILS_ENV"]    ||= "production"

[mtylty]

I completely agree. rails_admin should be completely unaware of which environment is running in, right?

We should ask the rails team about it...

[mtylty]

Yep, it seems rails related rails/rails#2805

Seems like a problem which also has been found on sass-rails.

[mtylty]

Ok guys, it seems that this issue has already been solved by @guilleiguaran, ( rails/rails#2768 ).
If you want a quick fix you should either use

gem 'rails', :git => 'git://github.com/rails/rails.git', :branch => '3-1-stable'

in your Gemfile or wait for rails 3.1.1 to be released :)

I'm closing this issue.

[crosebrugh]

FWIW, I'm on Rails 3.1/ruby 1.9.2 and want a clean production precompile (such that I could have config.assets.compile = false in production.rb so realtime compilation never happens).

I had to do the following things to make this work:

• use the rake task in https://gist.github.com/1185448 instead of the builtin assets:precompile

• vendor the rails_admin gem. This is wise to do for production apps anyway since it's not really versioned yet. I do this by:

    % (cd vendor/git ; rm -rf rails_admin ; git clone git://github.com/sferik/rails_admin.git ; rm -rf rails_admin/.git)
  

  and having

    gem 'rails_admin', :path => 'vendor/git/rails_admin'
  

  in my Gemfile

• in the rails_admin gem, rename app/assets/javascripts/rails_admin/rails_admin.js to app/assets/javascripts/rails_admin/application.js

• in the rails_admin gem, rename app/assets/stylesheets/rails_admin/rails_admin.css to app/assets/stylesheets/rails_admin/application.css

• in the rails_admin gem, change references in app/views/layouts/rails_admin/main.html.haml from rails_admin/rails_admin.(css,js) to just rails_admin/application (no suffix)

I don't know how much of this is that no one else has tried to production deploy with these requirements (no dynamic compilation of assets) or if I've missed something that's simpler to do, but it is working as intended.

[guilleiguaran]

FYI, Rails 3.1.1 will be released in the next days (the RC will be out today or tomorrow) and you won't need the custom rake task anymore.

@tlatim, I will be checking rails_admin in the next days to see if I can do the assets handling better for Rails 3.1

[mtylty]

@tlatim, I think you can skip the vendoring and renaming if you add:

config.assets.precompile += %w(... rails_admin/rails_admin.js rails_admin/rails_admin.css)

to your production environment file.

I know it's just a quickfix but I think it saves a lot of precious time :)

[andreierdoss]

Workaround for Heroku. This happens to me only if I have settings in the rails_admin.rb initializer, specifically ones that call 'config.model'. After I commented it out, I deployed successfully and it ran rake assets:precompile on Heroku. Afterwards I reenabled the rails_admin config and the app ran successfully.

[banane]

What fixed our heroku error was to set the environments/production.rb "config.assets.compile = true ". Not optimal. Still don't really know what is going on here.

[likethesky]

So combining all the good work above, for Heroku, to make:

RAILS_ENV=production bundle exec rake assets:precompile

work correctly ( as recommended here: http://devcenter.heroku.com/articles/rails31_heroku_cedar ), we added in the correct spot (search on 'precompile') in config/production.rb the line:

  config.assets.precompile += %w(... rails_admin/rails_admin.js rails_admin/rails_admin.css)

and then we replaced the assets.rake task called ':precompile' (you'll find assets.rake buried in ActionPack) with the gist ( https://gist.github.com/1185448 ) specified by @tlatim above--we left in the task at bottom and just replaced lines 2-54 with his gist.

Works for us, and we've now successfully deployed rails_admin to Heroku with precompiled assets, in production.

[bbenezech]

You don't need config.assets.precompile += %w(... rails_admin/rails_admin.js rails_admin/rails_admin.css) anymore.
RailsAdmin does it for you now.
And I don't know why you need to monkey path the precompile task? I have no problems without it.

And actually you don't need to precompile at all, now Heroku should do it for you automatically at slug creation time.

You just need to set that:

config.assets.initialize_on_precompile = false

So that initializers won't run (especially RA's one) and won't try to access variables and DB which aren't loaded by Heroku when compiling slugs.

Cheers.

[likethesky]

Yes, you can ignore my instructions above if you are running on Rails 3.1.1, although @bbenezech's solution doesn't seem to work (for me) with Rails 3.1.0, it does work for Rails 3.1.1 and the latest RailsAdmin.

Important to note (because all of the above posts talk about putting the 'config.assets.precompile' line in config/production.rb) that in the case of:

config.assets.initialize_on_precompile = false

that the above does not go in config/production.rb (wrong!), but instead goes in:

config/application.rb

HTHs!

[svoynow]

Still having a related problem. It seems like if you have a :validates_acceptance_of on one of your models, this will cause the rake task to try to initialize a database connection.

[kevinwmerritt]

@bbenezech You will need to specify the rails_admin assets if you are already specifying something else.

For example, I previously had the following production.rb config:

config.assets.precompile += %w( modernizr.js )

This prevented Heroku from loading the rails_admin assets. To fix:

config.assets.precompile += %w( modernizr.js rails_admin/rails_admin.js rails_admin/rails_admin.css )

[databyte]

I have config.assets.initialize_on_precompile = false and regardless rails_admin/* being listed or not, I get this:

   Running: rake assets:precompile
   rake aborted!
   Undefined variable: "$red".
   (in /tmp/build_1xplh10wee60b/vendor/bundle/ruby/1.9.1/bundler/gems/rails_admin-7a4fdd931f95/app/assets/stylesheets/rails_admin/base/theming.css.scss)

   Tasks: TOP => assets:precompile:primary
   (See full trace by running task with --trace)
   Precompiling assets failed, enabling runtime asset compilation
   Injecting rails31_enable_runtime_asset_compilation

So I guess it's just more of a function of fixing it so that this can precompile while initialize_on_precompile is false.

[x2002g]

I'm using Rails 3.2 and all these solutions don't work for me, some of them are even not easy to try. I'm working on a project with many js and css files. It's a nightmare to list all these files for config.assets.precompile. I saw many people asked similar questions but no easy and useful solutions. Why not just change "$red" to "red" to be more compatible and save some time?

[databyte]

Yeah, the fix was that my precompile was too greedy and grabbing the files for this.

All you need is "rails_admin/rails_admin.css" on the css front.

[parkr]

@databyte In an effort not to have to update my list of assets often, I am using a "greedy" precompile which is tailored for compass.

# Precompile *all* assets, except those that start with underscore
config.assets.precompile << /(^[^_\/]|\/[^_])[^\/]*$/

How would you go about fixing this regex so it just grabs the specified rails_admin assets?

[databyte]

@parkr I would change that regex to exclude anything in rails_admin as well, then just add on the items needed in rails_admin explicitly.

/(?<!rails_admin)(^[^_\/]|\/[^_])([^\/])*.css/

Example output: http://rubular.com/r/tzibTpNw1L

The greedy * on the end of the original query allowed the statement to be applied across each folder within a single string, by placing the file extension on the end - it allows it to match just the filename instead of the folder as well. Obviously you could change the css to check for other file types as well or just a literal dot followed by {1,3} or more characters.

[parkr]

Unfortunately, this regex does not solve the problem. Check it out.

[databyte]

I think the regex at that point is just getting too messy because the lookbehind query is based on the matching query which in your case is the filename. When it goes backwards from the match, it finds the sub-folder (base) and not the root (rails_admin). I'm sure someone on StackOverflow would be willing to figure it out.

Personally I would just do it the way most everyone else does - use a manifest file that lists the root files you need and those in term reference your other files. For instance, the only reason why you have to link to rails_admin/rails_admin.css is because it contains:

/*
 *= require rails_admin/imports.css.scss
*/

which then references all the other files:

@import "rails_admin/base/theming";
@import "rails_admin/themes/<%= theme %>/theming";
@import "rails_admin/custom/theming";

Create an application.css that imports all the other files you need. It helps to clean out your old files too since you can dereference those that aren't needed and compare your cache folder to your file list to see what didn't compile.

[parkr]

The issue is that I want to have module-specific files CSS for my main site. The tradeoff is between 1 gigantic CSS file and 2 much smaller files. Why have one huge CSS file if 65% of the styles aren't used on any given page? The Rails way of conglomerating everything together doesn't make a lot of sense for my app (trying to be speedy on mobile devices).

Thanks for your help!

[databyte]

I have several root files instead of one gigantic one but, yeah, I do have them.

The benefit of having a manifest file is that compressing several assets into one is faster for the client (especially a mobile client) since it doesn't have the overhead of extra TCP connections for more assets. So if your welcome page for a mobile device can have a single 4K asset vs 4x 1X assets, it'll be faster overall.

Post your solution when you have it in case anyone stumbles across this later. It took longer than a couple mins for me so I bailed on it.

[parkr]

Solution was given by a helpful StackOverflow member:

# Precompile *all* assets, except those that start with underscore or start with 'rails_admin'
config.assets.precompile << /^(?!rails_admin)(?:.+\/)?(?!_)([^\/]*).s?css$/