I'm trying to upgrade an app that's already deployed to Heroku to use the asset pipeline in Rails 3.1. I followed all the necessary steps in RailsCasts #282 and my app runs fine locally. However, when I push to Heroku and try to access the root path, I'm getting errors of the sort "foobarbaz.png" is not precompiled. If I remove the first image from the page, I get the same error for the next one down, and so on. All the images have been pushed to Heroku, so there's no case of trying to reference images that aren't there.
I noticed that when I pushed the app to Heroku, I did/do not see the following output:
-----> Preparing Rails asset pipeline
Running: rake assets:precompile
I've tried running rake assets:precompile locally and keep getting the following error:
rake aborted!
production database is not configured
There's no production configuration in my database.yml file due to using Heroku. When I try to run heroku run rake assets:precompile, I get the following error:
rake aborted!
Application has been already initialized.
I've added the necessary lines to application.rb and my environment files, and I just can't seem to get it working!
That problem happened to me as well, and in my case it was because I had the following line on my config/application.rb
config.assets.initialize_on_precompile = false
It seems to be needed in some versions of Rails according to Heroku (https://devcenter.heroku.com/articles/rails-asset-pipeline),
While precompiling assets, in Rails 3.x, you can prevent initializing
your application and connecting to the database by ensuring that the
following line is in your config/application.rb:
config.assets.initialize_on_precompile = false
but in my case it was throwing the 'Application already initialized' exception, and that went away after I've removed it
Since Heroku logs weren't really helpful when deploying, the way I've tested it was to run the assets precompile rake task on my heroku instance:
heroku run rake assets:precompile
Heroku assumes you are doing your own precompiling (which you are having a problem with) if the file manifest.yml is present.
REMOVE manifest.yml from your public or public/assets folder.
Push the changes to heroku. Example below.
$ git rm public/assets/manifest.yml
$ git commit -m "remove precompile manifest"
$ git push -f heroku master
Run assets:precompile on heroku server. Enter:
$ heroku run rake assets:precompile
Related
I get the following error after deploying my Yeoman app to Heroku
GET http://myapp.herokuapp.com/favicon.ico 503 (Service Unavailable)
I have a favicon image, and everything runs fine locally with the favicon image appearing. I'm not sure how to fix this error or why it is being caused in the first place.
Here is all my code: https://github.com/dkretsch12/MyHerokuApp
And I push it to Heroku with the following commands:
git add .
git commit -am "still stuck"
git push heroku master
I also ran into this, and for me it turned out the '503 (Service Unavailable)' error was not the real error.
Try:
heroku logs --app [your-app-name]
and see if it gives you more info.
In my case it was that Heroku was looking for npm start script, which I had not specified, but is required by Heroku.
Looking at your package.json I see you don't have it either, so that might be the place to start.
edit
I think the underlying reason for this error is that by default Heroku expects a webserver or some kind executable to be running in the background. It's needed because otherwise incoming requests would not be handled. So it has to be provided by the programmer, and after installation Heroku will run it, either by npm start or by what is specified in the Procfile.
I my case I needed a webserver anyway, so I just created a server.js module where I implemented a small express app. Then in package.json I specified:
"scripts": {
"start": "node server.js",
...
},
But this may not be the right solution for you, it depends on what you want with your app. I don't know anything about Grunt or Angular, so I can't help you there. I did find this question which may be of value to you. I also recommend reading the docs on Heroku Dev Center
I had the same 503 service unavailable error favicon.ico, when attempting to open a Heroku deployed Rails/React app. I was stuck on this bug for at least an hour, and thought this post may provide insight on how I solved the 503 favicon issue.
Step 1: I tried to locate a favicon.ico file in my rails app, tried creating my own favicon.ico file, and placing said file in the root and other directories. I got the same error...
Step 2. I ran the following in terminal: heroku logs -t, scrolled up and found the actual error to be Heroku failing to support gem sqlite3.
An error occurred while installing sqlite3 (1.3.13), and Bundler cannot
remote: continue.
remote: Make sure that `gem install sqlite3 -v '1.3.13'` succeeds before bundling.
remote:
remote: In Gemfile:
remote: sqlite3
remote: !
remote: ! Failed to install gems via Bundler.
remote: ! Detected sqlite3 gem which is not supported on Heroku:
remote: ! https://devcenter.heroku.com/articles/sqlite3
More info as to why is here.
Step 3: After learning more, I discovered I can either follow the heroku documentation to figure out how to use sqlite3 with heroku, or change DB. I chose to change DB to postgres, and I found two amazing resources to help with that:
how to change your rails app database from sqlite to postgresql before deploying to heroku.
Change from SQLite to PostgreSQL in a fresh Rails project
Step 4: After doing so, I got a 500 internal server error, went to heroku logs -t again, and found out that my tables did not exist on heroku. From there, I knew I had to migrate rails DB to heroku using the following command: heroku run bundle exec rails:db migrate. Pushed to heroku and that did the trick.
TLDR: A status 503 unable to find path="/favicon.ico" doesn't necessarily mean the issue stems from a missing favicon.ico in a heroku deployed app. A more insightful method for determining root cause is to use heroku logs -t.
When I run bundle exec rails console production or rails console production via SSH on the server in the Current folder of the Capistrano deploy I get:
Usage:
rails new APP_PATH [options]
Options:
(...)
with an explanation to start a new app. Locally it works. Why can't I start a console remotely?
I'm assuming that you updated to rails 4 from version 3 and your app can't find the executables in the bin directory. Run this to see your rails version:
$ rails -v
If your rails version is 4 or above, try running this:
$ rake rails:update:bin
Source: Rails 4 Release Notes
6.1 Notable changes
Your app's executables now live in the bin/ dir. Run rake rails:update:bin to get bin/bundle, bin/rails, and bin/rake.
I am using capistrano to deploy, including the capistrano/bundler gem. Since the ./bin directory is version controlled in Rails 4, we need to prevent Capistrano from linking it on deployments by removing bin from set :linked_dirs.
Now in order to prevent bundler from overwriting the version controlled binstubs, we can add the line set :bundle_binstubs, nil which will prevent capistrano-bundler from setting the --binstubs option when running bundle install.
My config/deploy.rb file now has these lines:
# Default value for linked_dirs is []
set :linked_dirs, fetch(:linked_dirs, []).push('log', 'tmp/pids', 'tmp/cache', 'tmp/sockets', 'vendor/bundle', 'public/system')
set :bundle_binstubs, nil
Note the lack of the bin directory in the :linked_dirs line.
I have the same problem, and turns out when you deploy through cap shared/bin is symlink to current/bin.
Here's what works for me:
rm current/bin
mkdir current/bin
rake rails:update:bin
This should help, but it is somewhat a temporary solution, I'm trying to find out how to make cap not auto symlink-ing current/bin.
In case of Rails 5.2
I had to remove bin directory by running below command in project root directory.
rm -rf bin
and then I ran another command in project root directory:
rake app:update:bin
It will show you output like below:
create bin
create bin/bundle
create bin/rails
create bin/rake
create bin/setup
create bin/update
create bin/yarn
That's it.
It's been a little while since this was answered.
In my case I needed to run:
rake app:update:bin
Note- app rather than rails.
I was missing the bin directory all-together in my Rails 5.1 App
I faced this issue on my production server when I updated my application from Rails 5.2 to 6.0.4. Simply follow these steps:
cd to_your_project_dir
rm -r bin
rake app:update:bin
The documentation here says that heroku with pre-compile assets during deployement in Rails4.
However ,
I dont see the precompile assets message.
Using thin (1.6.1)
Using twitter-bootstrap-rails (2.2.8)
Using uglifier (2.3.1)
Using will_paginate (3.0.4)
Your bundle is complete! It was installed into ./vendor/bundle
Bundle completed (1.37s)
Cleaning up the bundler cache.
-----> Writing config/database.yml to read from DATABASE_URL
Detected manifest file, assuming assets were compiled locally
-----> Discovering process types
Procfile declares types -> (none)
Default types for Ruby -> console, rake, web, worker
I am facing issues with bootstrap in my app, where the nav bar wont load properly + some other nuances and I think its the asset precompile issue.
I am using Rails4, Ruby2.0
I have assets enabled in application.rb
config.assets.enabled = true
Precompiling manually did not help
heroku run rake assets:precompile
Had this same problem. I had precompiled locally for some reason and then pushed to Heroku.
Saw Heroku give the line "Detected manifest file, assuming assets were compiled locally" which made me realize it wasn't precompiling all the things.
When I did a "git add ." and committed, I saw that it was adding a bunch of public files. Pushing that to Heroku got it to work. So I had to precompile and git add everytime, basically doing Heroku's work for it and making a mess in my public folder. It got the job done, but was a poor fix.
I looked for the "manifest" that heroku mentioned and eventually found a ".sprockets-manifest..." file in the public directory.
Deleted that and Heroku was once again my friend.
Found this question as part of my research so I thought I'd share what I found in case anyone else sees this, or has any elaborational thoughts.
Now I have to go and see if .sprockets-manifest was important to anything else ....
I struggled with the asset pipeline for a while. There seems to be a bit of confusion as to how the asset pipeline works among newer Rubyists. In my experience, this is my workflow to the asset pipeline for Heroku.
Make sure that assets work locally on localhost (required for Heroku)
Delete the public/assets folder in the Rails directory with rm -rf ./public/assets
Make a new assets directory with mkdir public/assets
Run the rake assets:precompile command
You should see a list of assets being precompiled in your command line
Once assets are precompiled, you should commit the changes via the following commands: git add -A then git commit -am "commit message goes here"
Finally, push to heroku via git push heroku master
NOTE: This bears repeating -- make sure your assets work normally on localhost before pushing to Heroku.
Deleting the public/assets folder helped. Also I ran heroku run rake assets:clean.
After that I could see:
----> Writing config/database.yml to read from DATABASE_URL
-----> Preparing app for Rails asset pipeline
Running: rake assets:precompile
The navbar loads fine now !
The message Detected manifest file, assuming assets were compiled locally is shown if there is .sprockets-manifest-*.json or manifest-*.json in public assets. So either removing individual file or whole public/assets works.
The source code for buildpack is here
We are dealing with an issue where our assets are compiling w/o any issues during slug compilation. However, starting yesterday after a push to both our staging and production applications, we are now running into issues where the browser is indicating that the assets can't load for some reason.
Using the browser dev tools we are seeing this error:
Failed to load resource: the server responded with a status of 404 (Not Found) :
/assets/application-a3b17e738ce8996d058795310e3cd9b4.js
The first thing we decided to do was rollback our codebase to the last commit (which was the commit that was fully functional in a previous heroku push). The same issue exists where the browser can't load the asset.
Using bash, I connected to the heroku instance and checked out the public/assets directory to ensure the assets were actually there. They are ALL there with the correct hash codes preceding the file names. The files are not empty and the manifest file looks good to go.
I'm not sure what else to try at this point. We've never had issues until now with loading of assets. There is nothing in the heroku push logs that indicate anything is throwing an error at any point.
I had the same issue. It seems to be fixed for me after including the rails_12factor gem in my production gems (in my Gemfile). I found this out after reading the first part of this Heroku Support page: https://devcenter.heroku.com/articles/rails4
Logging and assets
Heroku treats logs as streams and requires your logs to be sent to STDOUT. To enable STDOUT logging in Rails 4 you can add the rails_12factor gem. This gem will also configure your app to serve assets in production. To add this gem add this to your Gemfile:
gem 'rails_12factor', group: :production
This gem allows you to bring your application closer to being a 12factor application. You can get more information about how the gem configures logging and assets read the rails_12factor README. If this gem is not present in your application, you will receive a warning while deploying, and your assets and logs will not be functional.
The 'rails_12factor' gem has gem dependencies on the rails_serve_static_assets gem and rails_stdout_logging. Basically, if you don't want your Rails app using its precious cycles on processing requests just to serve assets then you'll need to figure out a different solution such as a CDN: https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn-with-rails
I have an app which I have pushed successfully several times which has just started crashing when I try to push it to heroku.
I thought the only change I made was to a yaml config file and so I replaced that file with an earlier version but the crash continues. Any thoughts on how to track this down?
heroku[web.1]: Starting process with command `bundle exec thin start -R config.ru -e production -p 38838`
app[web.1]: /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.9/lib/active_support/dependencies.rb:251:in `require': cannot load such file -- rails_config/sources/yaml_source (LoadError)
app[web.1]: from /app/vendor/bundle/ruby/1.9.1/gems/rails_config-0.3.1/lib/rails_config.rb:4:in `<top (required)>'
[Added - 12/13/12] Interestingly - cloning the local repo and creating a new Heroku app with it works fine, so it looks to be something with the instance rather than the repo. Touching a file an redeploying doesn't fix it tho'.
Turns out this was a problem in the .slugignore.
I diagnosed this by looking at how Heroku built the bundle and reproducing that locally:
bundle install --without development:test --path vendor/bundle --binstubs bin/ --deployment.
Checking the resulting bundle I confirmed that the missing yaml_source file (from rails_config) was indeed present. Then I remembered half noticing that the slug compiler had said that it was removing 3 files rather than the usual 1.
I have a top level 'sources' directory which I was trying to exclude with
sources
in the .slugignore file. This was matching the sources directory in the gem. Changed the entry to the intended
/sources/
and all is good again.
This leaves the observation that Heroku seems to be using different versions of the Slug Compiler in different instances and it appears to have changed. (My app works on a different instance and .slugignore file has been incorrect for a long time)