Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

No indicator that Rake failed #9

Closed
bcardarella opened this Issue · 19 comments

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
Owner

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

@hone
Owner

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
Owner

@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

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
Owner

@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

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
Owner

@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
Owner

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

@jodell

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

@hone
Owner

This should be solved by #34 .

@hone hone closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.