Could not detect rake tasks - heroku

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.

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.

Capistrano cap production deploy fails on migration but cap production deploy:migrate passes

I've come across a strange problem with Capistrano while getting a production server ready. When I run cap production deploy, it always fails on the deploy:migrate step with
ActiveRecord::AdapterNotSpecified: 'production' database is not
configured. Available: ["defaul…
Yet, when I run cap production deploy:migrate, Capistrano completes successfully.
On the actual server, I am able to run RAILS_ENV=production bundle exec rake:migrate without any problems either.
The Capistrano log spits out the same command for both:
[deploy:migrate] Run rake db:migrate
My database config looks like this:
production:
adapter: mysql2
encoding: utf8
database: foo
host: localhost
pool: 5
timeout: 5000
username: bar
password: password
socket: /opt/bitnami/mysql/tmp/mysql.sock
I should also mention that I have set the rails env in my deploy.rb like so: set :rails_env, :production
Here is the relevent information in my gemfile:
gem 'mysql2', '~> 0.4.5'
group :development do
gem 'capistrano', '~> 3.6', '>= 3.6.1'
gem 'capistrano-rvm'
gem 'capistrano-bundler'
gem 'capistrano-rails'
gem 'capistrano-passenger'
end
Can anyone shed some light on what I am missing here? I am new to Capistrano.
After a lot of searching I found the root cause.
I didn't realise that the "current" directory (or symlink to be fair) is created at the end of the Capistrano process and since I had an earlier trial run with RAKE_ENV=development, I already had the current symlink on the server.
Before the deploy:migrate step, I upload my database.yml from a secure location to the server via a custom task that uses this command:
upload! "#{SECURE_DATA}database.yml", "#{current_path}/config/"
Which at the time of before deploy:migrate, which to my confusion, I thought the rake db:migrate was being run from the current symlink, but it was in fact being run from the latest release directory. The latest release directory did not have the production database information as the file was uploaded to the current symlink which pointed to an old release.
All in all, my custom task caused this problem and if anyone else comes across a similar scenario, us this command instead:
upload! "#{SECURE_DATA}database.yml", "#{release_path}/config/"
The key being the release_path variable instead of the current_path variable.

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.

Capistrano v3 is trying to load ssh-kit twice and throwing a warning

I am trying to capify a project and when I run bundle exec cap staging -T
I get a warning
/usr/local/Cellar/rbenv/0.4.0/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/sshkit-0.0.34/lib/sshkit.rb:3: warning: already initialized constant SSHKit::StandardError
/usr/local/opt/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/sshkit-0.0.34/lib/sshkit.rb:3: warning: previous definition of StandardError was here
and then the output of the command including the list of tasks
cap deploy # Deploy a new release
cap deploy:check # Check required files and directories exist
...
I have tried removing all the other gems from bundler that would conflict with this but it seems like bundler itself locks this file at versions 2.6.6. I dont even know if it is bundler causing that problem.
Current version of sshkit is 1.3.0. Try running
$ bundle update
and write if you will still have problems. Sometimes the command:
$ gem outdated
can be useful for detecting old versions of gems.
It probably a problem related to symlinks inside rvm/rbenv/… it could be resolved avoiding require_relative inside the sshkit gem but in the meanwhile I think the only option is stick with the error and wait for this issue to be resolved.

Rails 3.2.3 Asset Pipeline precompile does nothing

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.

Resources