Assets don't get precompiled after "rake assets:precompile", throws error 500 - Internal Server Error #307

Closed
gaurish opened this Issue Apr 20, 2012 · 9 comments

Comments

Projects
None yet
3 participants
Contributor

gaurish commented Apr 20, 2012

I am running my app on Heroku & trying to run surveyor gem results in the following error:

Started GET "/surveys" for 59.95.173.8 at 2012-04-16 18:51:09 +0000
Processing by SurveyorController#new as HTML
Rendered vendor/bundle/ruby/1.9.1/gems/surveyor-0.22.0/app/views/surveyor/new.html.haml within layouts/surveyor_default (1.5ms)
Completed 500 Internal Server Error in 62ms

ActionView::Template::Error (surveyor/reset.css isn't precompiled):
4: <head>
5:   <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
6:   <title>Survey: <%= controller.action_name %></title>
7:   <%= surveyor_includes %>
8: </head>
9: <body>
10:   <%= yield %>

so, it turns out surveyor assets(css, scripts) do not get precomiled. I verified, this by enabling runtime compile & app started working but it is slow.
here is the entire log:
https://gist.github.com/2430092

Ideally, the following assets should be added into asset path, so they get autocompiled by asset pipeline when assets:precompile rake task is executed.

Currently this does not happen & hence it needs fixing by adding assets to correct path

Rails Version: 3.2.2
Heroku Stack Cedar
Surveyor: 0.22.0

Contributor

jefflunt commented Apr 20, 2012

Since the surveyor assets are in the vendor folder (as opposed to a
sub-folder of app/assets), you should theoretically be able to take this
question/answer from StackOverflow, and include the vendor assets in the
ones that get compiled. Assuming that works, that'll solve your Heroku
problem.

http://stackoverflow.com/questions/9006823/rails-asset-pipeline-standard-way-for-including-all-vendor-assets-javascripts

Also, this RailsCast includes notes on how to include assets from gems,
which might also be useful.

http://railscasts.com/episodes/279-understanding-the-asset-pipeline?view=asciicast

-Jeff

On Fri, Apr 20, 2012 at 11:22 AM, Gaurish Sharma <
reply@reply.github.com

wrote:

I am running my app on Heroku & trying to run surveyor gem results in the
following error:

Started GET "/surveys" for 59.95.173.8 at 2012-04-16 18:51:09 +0000
Processing by SurveyorController#new as HTML
Rendered
vendor/bundle/ruby/1.9.1/gems/surveyor-0.22.0/app/views/surveyor/new.html.haml
within layouts/surveyor_default (1.5ms)
Completed 500 Internal Server Error in 62ms

ActionView::Template::Error (surveyor/reset.css isn't precompiled):
4: <head>
5:   <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
6:   <title>Survey: <%= controller.action_name %></title>
7:   <%= surveyor_includes %>
8: </head>
9: <body>
10:   <%= yield %>

so, it turns out surveyor assets(css, scripts) do not get precomiled. I
verified, this by enabling runtime compile & app started working but it is
slow.
here is the entire log:
https://gist.github.com/2430092

Ideally, the following assets should be added into asset path, so they get
autocompiled by asset pipeline when assets:precompile rake task is executed.


Reply to this email directly or view it on GitHub:
#307

Contributor

jefflunt commented Apr 20, 2012

Also, when you enable run-time compiling, doesn't it only compile when needed (e.g. the first time the relevant assets is requested)? Wouldn't that mean that you would only see the slowness after a short "warm up" period when your Heroku app is freshly deployed?

Contributor

jefflunt commented Apr 20, 2012

Paul and I replicated your issue, and we found the deeper problem that you're referring to.

So, in Rails 2, we didn't have the asset pipeline. Since surveyor has its roots in the Rails 2 time period, there's some code in surveyor that explicitly references what is essentially the non-compiled version of the assets. This is why, when you're deploying it in Rails 3, if you don't have run-time compilation enabled, your app falls over.

So, the solution to this, we think, is:

  • Short term - turn on run-time compilation in your app. It should only be slow the first time that asset is hit, and therefore compiled. Requests after the initial compilation should be normal speed.
  • Long term - we need to change the way we're including those assets for the Rails 3 version of surveyor, such that they're properly included in the pipeline, as you noted. This involves removing some old helpers (and their references).

This means we don't have a quick, Friday-afternoon fix for you, I'm afraid. However, I think we found what needs to change.

Contributor

gaurish commented Apr 21, 2012

@normalocity
thanks for replicating the issue & confirming the bug.

  1. Short Term: Yes, run-time compilation makes the app which otherwise would just give 500 - internal server error.
    though, its painful fix as heroku idles out app after 60minutes of non-activity. So, asset compilation process
    which takes about 7-8seconds has to be repeated each time which would impact the performance. But its
    good as short term solution.
  2. Long Term: Which old helpers
    need to be removed or what else needs to be done so that surveyor's assets can get precompiled?
  3. Assets Path: I know we can manually set assets path using config.assets.precompile += ['someramdomstylesheet.css']
    but I think it can be done automatically as well. Because there are gems bundling assets & those assets get precompiled
    when rake assets:precompile is run example is bootstrap-sass gem. Further, rails asset guide states
    that Inheriting from Rails::Engine would inform Sprockets about the assets. so it would be cool if this can be done automatically as it would mean less step for initial setup.
  4. Assets not in asset path: the following assets are missing from assets path
    1. surveyor/reset.css
    2. surveyor/dateinput.css
    3. surveyor/jquery-ui.custom.css
    4. surveyor/jquery-ui-timepicker-addon.css
    5. surveyor.css
    6. custom.css
    7. surveyor/jquery.tools.min.js
    8. surveyor/jquery-ui.js
    9. surveyor/jquery-ui-timepicker-addon.js
    10. surveyor/jquery.surveyor.js
    11. surveyor/jquery.blockUI.js

Lastly, do you accept patches?

Contributor

jefflunt commented Apr 22, 2012

Sure we accept patches. Just submit a pull request with any tests that are appropriate.

There are helpers included in the application view layouts that specifically call the assets, and include them in the page. Those helpers need to be replaced with an alternate, asset-pipeline-sensitive way of doing things.

As for the spin-down on Heroku, you can use a free service such as pingdom.com to hit the front page of your app, say every 5 minutes. This will prevent Heroku from spinning down your app, and will therefore allow you to retain any compiled assets. It's a hack, but it should work for you for now.

Contributor

gaurish commented Apr 22, 2012

Cool, so I would give it a try & try to switch those. any links or resources that would explain codebase/codelayout?

about heroku spin-down.
yes. that's exactly what I have done. signed up for new relic instead of pindom because its much more than a plain http monitoring service. thanks for the suggestion

Contributor

jefflunt commented Apr 23, 2012

This file: https://github.com/NUBIC/surveyor/blob/master/lib/surveyor/helpers/surveyor_helper_methods.rb

These helpers are called by the page layouts. Their functionality needs to be replaced.

def surveyor_stylsheets
  stylesheet_link_tag 'surveyor/reset', 'surveyor/dateinput', 'surveyor/jquery-ui.custom', 'surveyor/jquery-ui-timepicker-addon', 'surveyor', 'custom'
end

def surveyor_javascripts
  javascript_include_tag 'surveyor/jquery.tools.min', 'surveyor/jquery-ui', 'surveyor/jquery-ui-timepicker-addon', 'surveyor/jquery.surveyor', 'surveyor/jquery.blockUI'
end
Contributor

jefflunt commented May 4, 2012

I'll bring this up to the group here. We had a discussion about how to really solve this the other day, without breaking backward compatibility (with Rails 3.0+ apps, pre-asset pipeline). Thanks for the patch - hopefully this will get us closer to a permanent solution, or at least give us another way to look at the problem.

Contributor

gaurish commented May 4, 2012

Sure, no problem :)

yoon closed this in a779e2e May 7, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment