Rails 3.2.3 Asset Pipeline precompile does nothing - ruby-on-rails-3.1

I can reproduce this issue on both OSX and Windows with Ruby 1.9.2:
I have a simple Rails 3.2.3 app and am trying to precompile the assetpipeline, but the assets:precompile does nothing. Doesn't complain either.
Here is what I've done:
Using RVM, create a new and clean gemset, call it rails32
Install rails: gem install rails -v 3.2.3
Create a dummy scaffold: rails g scaffold test name:string
Migrate the prod db: rake db:migrate RAILS_ENV=production
Run the server in prod: rails s -e production
At this point I get the asset not precompiled exception, which I was expecting. Then:
I run rake assets:precompile RAILS_ENV=production
It runs with no errors and ends.
After that, my app has fingerprinted assets in the HTML but they don't exist anywhere.
Any ideas? I thought this is the simplest form of using the assetpipeline.

By default, Rails expects a high-load server (such as Apache or nginx) to serve static assets in production mode. If you really don't want to run your app behind such a server, in your config/environment.rb file, change config.serve_static_assets to true.

Related

Ruby: Unable to start worker - check_for_activated_spec

I am unable to run some of my jobs in sidekiq. And it seems to be somehow related to Bundler.. Maybe.
when I run my puma server with pumactl start in the logs I am getting:
[156149] ! Unable to start worker
[156149] /home/todd/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/bundler-2.3.25/lib/bundler/runtime.rb:309:in `check_for_activated_spec!'
Currently I'm on sidekiq 6.5.6 and Bundler 2.3.25
Anyone know of any issues with those two versions or anything else that may be causing this?
EDIT:
The interesting thing is when I start puma with bundle exec pumactl start I get a totally different error:
[ActionDispatch::HostAuthorization::DefaultResponseApp] Blocked host:
But my host is defined in my development.rb file.. in fact I've added the following, so NO hosts should be blocked:
config.hosts << /.*\.ngrok\.io/
config.hosts.clear
Then finally if I just start puma with a rails s all is fine, just my sidekiq worker won't run correctly.
Let's say that you want to start using Rails and one day you follow the general installation instructions which say that you should run this command:
gem install rails
And you get this output:
...
Successfully installed rails-7.0.1
You also start working with puma and sidekiq and install those gems for the convenience of running pumactl start and sidekiq:
gem install puma
...
Successfully installed puma-5.6.2
gem install sidekiq
...
Successfully installed sidekiq-6.4.2
Then after a day or a week or a month of tinkering you create a new Rails app:
rails new app
And since you want to use Sidekiq you add that to your Gemfile, which looks something like this:
# frozen_string_literal: true
source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }
gem "puma", "~> 5.6.2"
gem "rails", "~> 7.0.1"
gem "sidekiq", "~> 6.0"
But you know that there are newer versions of those gems so you update your Gemfile to look like this:
# frozen_string_literal: true
source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }
gem "puma", "~> 6.0.0"
gem "rails", "~> 7.0.4"
gem "sidekiq", "~> 7.0"
And then you run bundle install and the gems update. Or maybe you don't change the versions, but some day run bundle update which uses the ~> versioning operator and updates the gems to newer versions.
Here's where you're going to start running into compatibility problems.
First problem:
When you installed the sidekiq and puma and rails gems to run their scripts like pumactl they were installed using gem install ... which installed them globally and with a specific version.
When you added them to your Rails app and updated the versions they were installed separately by bundler with specific versions that are noted in Gemfile.lock.
Now your global version of puma is 5.6.2 and your bundled version of puma is 6.0.0.
Trying to manage puma using an old version of the CLI with a new version of the gem isn't guaranteed to work and can introduce hard-to-pinpoint problems. The same is true of the rails and sidekiq gems and any gem with a CLI.
Second problem:
When you run scripts like pumactl they aren't necessarily going to look at your application's Gemfile.lock and they aren't guaranteed to see or respect bundler's configuration for your Rails app when it loads it.
When you run scripts prefixed with bundle exec (like bundle exec sidekiq) it uses bundler to look at your bundled environment and ensure that all the dependencies are properly loaded.
Trying to run a bundled application without bundle exec can introduce hard-to-pinpoint problems. The same is true for any gems that have CLI tools.
Short answer
Always use bundle exec ... to run gem CLIs in your app, whether it's bundle exec rails server or bundle exec puma or bundle exec sidekiq. This will ensure that your app is started or managed using the bundled gem rather than the global version.
If you see errors when starting your app using bundle exec ... then pay attention to them because they are indicative of actual problems that need to be addressed. Likewise, if you do see errors with bundle exec but don't see errors when starting your app using globally installed gems then pay attention to them because it means your app is not portable -- it's likely that it is papering over bugs to make the app run and that your app will not run on another computer.
Extended answer
pumactl start gives you an error -- probably because you aren't using bundle exec.
bundle exec pumactl start gives you a different error -- possibly because you're bypassing the standard way to start Rails; pumactl will read configu.ru and config/puma.rb and decide how it wants to start Rails. Use bundle exec rails server instead.
rails s doesn't load your sidekiq worker -- because you aren't using bundle exec rails s it likely can't see the things it's supposed to see to start properly, because it isn't using your bundled app config
Because the errors that you're reporting are due to a misconfiguration of your system and app I can't give you any more detailed answers. You need to fix your configuration first and determine which of the three different errors you're experiencing is valid. It's a lot of work to try to work through all three questions. A standard "vote to close" reason for questions is:
Needs more focus
This question currently includes multiple questions in one. It should focus on one problem only.
I'm not voting to close your question but I'm mentioning it in case it does get closed later.
I recommend that after you fix the misconfiguration you create a new post about that specific error with a minimal reproducible example.

Heroku: where did my gems go?

I have been deploying a Rails 3.2 application to heroku for several weeks now. I have also been executing rake tasks on the Cedar stack where my application is located.
One day after a deploy I noticed that rake was no longer working. I get, for example, the following:
$:~/dev/my_project$ heroku run rake -T
Running `rake -T` attached to terminal... up, run.7566
bundler: command not found: rake
Install missing gem executables with `bundle install`
Trying to run commands with bundle exec yields the same results.
What I've tried:
heroku run bundle install. This works and informs me that gems were installed into ./vendor/bundle. However, heroku run ls ./vendor/bundle yields only the following:
$:~/dev/my_project$ heroku run ls ./vendor/bundle/
Runningls ./vendor/bundle/attached to terminal... up, run.3458
bin ruby
bundle package. Although the deployment works it does not help my problem.
fiddling around with the rubygems-bundler gem (although I think this is now part of core bundler). This does not seem to have any effect.
On Heroku, gems are installed within the vendor/bundle/ruby/<version>/gems directory. I just checked my Heroku instance and confirmed this.
You are going to want to use bundle exec rake task because the gems are not in the users PATH.

Could not detect rake tasks

ensure you can run `$ bundle exec rake -P` against your app with no environment variables present
and using the production group of your Gemfile.
This may be intentional, if you expected rake tasks to be run
cancel the build (CTRL+C) and fix the error then commit the fix:
rake aborted!
I don't have any rake tasks that I'd like to run automatically. Should I just ignore this warning?
Effective December 05, 2013, Heroku added debug output to deploys using the Ruby build pack.
The error is triggered:
if the assets:precompile task does not exist or
if there is an error in the Rakefile.
Two common causes of errors in the Rakefile are referencing a dependency not available in production (such as rspec) or
expecting an environment variable to be present.
It's counter-intuitive because the app never runs without config vars, but Heroku's build process executes without config vars.
As per the error message, ensure you can run bundle exec rake -P RAILS_ENV=production with no environment variables present before pushing to Heroku (e.g. comment out your environment variables while running the aforementioned command).
Also, rest assured that rake's -P switch is harmless, so you can run it as much as you want until you fix this issue. This switch is used to display a list of all tasks and their immediate prerequisites. See Rake Command Line Usage if you want to double-check. The output may have over 200 lines, and look something like this:
rake about
environment
rake assets:clean
environment
rake assets:clobber
environment
rake assets:environment
rake assets:precompile
environment
rake db:_dump
...
rake tmp:pids:clear
rake tmp:sessions:clear
rake tmp:sockets:clear
I started getting this strange error all of a sudden yesterday. Heroku confirmed making an update to the Ruby buildpack...
It has to do with the Rakefile. Does your Rakefile require any files? Does it require your app files? If so, then the app should not raise exceptions when it is loaded without any config vars set.
It's counter-intuitive because the app never runs without the config vars set.
In my case, the Sinatra app was looking for database urls in the init file:
uri = URI.parse( ENV[ "REDISTOGO_URL" ])
This will raise an exception if there are no env vars set.
You may have the same issue with other database URL's, such as Mongo or Postgres.
So, protect against missing env vars:
if ENV[ "REDISTOGO_URL" ]
uri = URI.parse( ENV[ "REDISTOGO_URL" ])
...
You can check if it will work before pushing to Heroku by running bundle exec rake -P
Also, make sure all your tests pass after updating your init. Remove any cached init state by restarting Spork or similar.
Reference: Show Rakefile errors in Ruby deploys
you can also try enabling user-env-compile
heroku labs:enable user-env-compile
FWIW I just ran into this issue also.
It turned out that I had config.assets.css_compressor = :sass commented out, when there was a rake task referring to it in production.rb.
Very simple oversight, but that would cause rake assets:precompile to fail and thus cause this error.
Old question, but I ran into this issue just now, and there is a new fix for it. If you're using Ruby version <= 2.6.1, and Bundler 2.0.1, update Ruby to 2.6.3 ($ rvm install "ruby-2.6.3") and Bundler to 2.0.2 ($ gem install bundler '2.0.2'). Make sure to specify the new Ruby version in your Gemfile.
Unfortunately I can't tell you why this works, but it's worked for 3 other people on my team so far, so it's worth a shot.

deploy redmine on heroku - heroku run rake db:migrate -> and I got DEPRECATION WARNING

I'm trying to deploy redmine folowing this tutorial, but when I run this command
heroku run rake db:migrate
I recieve this message:
DEPRECATION WARNING:
You have Rails 2.3-style plugins in vendor/plugins! Support for these
plugins will be removed in Rails 4.0. Move them out and bundle them in
your Gemfile, or fold them in to your app as lib/myplugin/* and
config/initializers/myplugin.rb.
See the release notes for more on
this:
http://weblog.rubyonrails.org/2012/1/4/rails-3-2-0-rc2-has-been-released.
(called from at /app/Rakefile:7)
Plugins in
vendor/plugins (/app/vendor/plugins) are no longer allowed. Please,
put your Redmine plugins in the plugins directory at the root of
your Redmine directory (/app/plugins)
I put the plugin folder at redmine/lib in redmine/
And nothing hapens.
Any body can help me?
This has to do with the ruby buildpack - it has nothing to do with your application. Deploying a stock Ruby on Rails app will display this message.
Are you getting any errors running your application?

Heroku not loading bundler for non-web ruby app

I have a program that I wrote using ruby. It doesn't have any web interface, but I use bundler for dependency management.
On my local system, running the app is as simple as typing rake app:start, and it loads up just fine.
When I deploy to heroku, however, my app crashes with a cannot load such file -- bundler error.
My Procfile looks has this entry app: bundle exec rake app:start.
Any help is greatly appreciated.
The problem was that Heroku was not changing the GEM_HOME field to the vendor/bundle directory.
By adding the following config vars to Heroku, my app ran as expected:
GEM_HOME: /app/vendor/bundle/ruby/1.9.1
PATH: /app/vendor/bundle/ruby/1.9.1/bin:bin:node_modules/.bin:/usr/local/bin:/usr/bin:/bin
Adding these was done via the heroku config:set CONFIG_NAME=VALUE command.

Resources