When recently deploying an app to production a developer added:
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'
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.
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.
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.
We'll look into adding a way to show rake failing here because of loading issues.
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
why not have rake with with --trace the first go-around? It seems running it twice is unnecessary.
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
@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.
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.
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.
puts "Compiling assets"
puts 'Compiling assets...'
unless system('rake assets:precompile --trace > /tmp/assets')
puts '** Asset compilation failed! **'
@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.
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.
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.
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
Also, if the rake task fails it should output a URL to a Heroku article on why Rake is most likely failing
@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.
I understand. Would you like me to open another 'Asset Pipeline Deploy Strategy' issue to discuss?
maybe we can just use #15 here. Do you guys have sample repro code for this issue though?
We were bit by this recently and I think comparing the approach in #34 would be useful.
This should be solved by #34 .