No indicator that Rake failed #9

Closed
bcardarella opened this Issue Feb 29, 2012 · 19 comments

Projects

None yet

5 participants

@bcardarella

When recently deploying an app to production a developer added:

require 'ci/reporter/rake/rspec'

The gem is ci_reporter

to our Rakefile. On the next push to Heroku the app was crashing because the assets were non compiling. Once we discovered what the change was the fix was quick:

unless Rails.env == 'production'
  require 'ci/reporter/rake/rspec'
end

But there was no indicator from the push command that anything was wrong other than noticing that the assets compile message was missing https://gist.github.com/1942061

So the suggestion would be to output the result of the rake command, even if it barfs.

@halorgium

The problem will have been that your Rakefile will have not been able to load.
So when checking if the rake task is defined, it would have bombed out.

https://github.com/heroku/heroku-buildpack-ruby/blob/0a38d693baadaff693cf5573f4b135a4fccdf99a/lib/language_pack/ruby.rb#L425

I would suggest instead that an environment variable saying that assets should be compiled be added, that way the compilation is always attempted and will not silently fail.

@hone
Member
hone commented Apr 6, 2012

We'll look into adding a way to show rake failing here because of loading issues.

@hone
Member
hone commented Jul 20, 2012

Hi, I'm working on trying to make this better. I've come up with this: https://github.com/heroku/heroku-buildpack-ruby/tree/asset_pipeline_rake

@bcardarella @zapnap can you give me a repro case or test out that branch?

You can try it by adding the BUILDPACK_URL to your app.

heroku config:add BUILDPACK_URL=git://github.com/heroku/heroku-buildpack-ruby.git#asset_pipeline_rake
@bcardarella

why not have rake with with --trace the first go-around? It seems running it twice is unnecessary.

@bcardarella

also, this commit doesn't look like it prevents deploy if rake fails. Perhaps this is unpreventable with Heroku, once the deploy is kicked off no way to stop, but personally I wouldn't want a production deploy to complete if asset compilation fails

@hone
Member
hone commented Jul 21, 2012

@bcardarella This doesn't try to fail the build if assets:precompile fails. This just tries to run a trace if we can't detect the rake task properly. The rake task won't run more than once. We don't --trace because we don't want it on every case.

I'm not sure where it's failing.

@zapnap
zapnap commented Jul 21, 2012

Maybe I'm misunderstanding, but why wouldn't you fail the build if assets:precompile fails? I can't think of many scenarios there where I would want it to proceed if an associated Rake task (as in my scenario yesterday) aborted. In that scenario, even doing the equivalent of a Rake -T would raise because I had a very basic problem :). Agree that --trace shouldn't be default though, far too noisy for the average deploy.

@bcardarella

You should run rake -t and pipe the result into a file. You can simply puts "Compiling assets" and detect the exit code of rake. If it exited with error you dump the result of the file and abort the deploy. IMO that's what should happen.

@bcardarella

Something like:

puts 'Compiling assets...'
unless system('rake assets:precompile --trace > /tmp/assets')
  puts '** Asset compilation failed! **'
  puts File.open('/tmp/assets').read
  exit
end
@hone
Member
hone commented Jul 21, 2012

@zapnap @bcardarella it doesn't fail the build, b/c that's just not the point of this change. I'm trying to first come up with helpful output to debug why the assets:precompile task fails ambiguously. I believe @zapnap's issue the other day and the one opened up here was there's basically no output when the rake task is not detected. This branch tries to help solve that.

As for failing the build, I need to think about it more. I'm just not sure if there are people who depend on that behaviour atm. Even if we did fail the build, it wouldn't help you debug why. I think these are two different but related concerns.

@bcardarella

I guess I don't understand why the build should still proceed if the assets fail to compile. The production application will 500 when the assets are not compiled.

@zapnap
zapnap commented Jul 21, 2012

I think I'm with Brian on this one. Of course, the user could be choosing to explicitly push precompiled assets or enabled asset compilation on the fly. But that could be detectable as well and/or the Rake task no-op'd.

@bcardarella

Yeah, if the assets are pre-compiled the rake task should not run at all. Would it be OK to do:

unless Dir.exist?(File.join(Rails.root, 'public/assets'))
  # kick off rake
end
@bcardarella

Also, if the rake task fails it should output a URL to a Heroku article on why Rake is most likely failing

@hone
Member
hone commented Jul 23, 2012

@zapnap @bcardarella I understand your issue with failing the build when the assets:precompile rake task does not pass, but like I said above that's a different issue that we should discuss on and needs more thought on my part.

The buildpack already skips assets:precompile if we detect public/assets/manifest.yml: https://github.com/heroku/heroku-buildpack-ruby/blob/master/lib/language_pack/rails3.rb#L43

This change is just to fix the "no detection of rake" failure, which is obscure why that happens at all.

@bcardarella

I understand. Would you like me to open another 'Asset Pipeline Deploy Strategy' issue to discuss?

@hone
Member
hone commented Jul 23, 2012

maybe we can just use #15 here. Do you guys have sample repro code for this issue though?

@jodell
jodell commented Sep 24, 2012

We were bit by this recently and I think comparing the approach in #34 would be useful.

@hone
Member
hone commented Jul 18, 2013

This should be solved by #34 .

@hone hone closed this Jul 18, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment