I'm running into trouble trying to use a rakefile to deploy a Jekyll site. Following the instructions here, I've set up ssh keys and can get into my server without entering a password, so that works. However, when I try to run a test sync (e.g, rake deploy dry-run) I get an error. I've added rakefile.rb to my repo but when I try to run it I get an error:
rake deploy:dryrun --trace
rake aborted!
Don't know how to build task 'deploy:dryrun'
/Users/Christopher/.rbenv/versions/2.0.0-p0/lib/ruby/2.0.0/rake/task_manager.rb:49:in `[]'
/Users/Christopher/.rbenv/versions/2.0.0-p0/lib/ruby/2.0.0/rake/application.rb:142:in `invoke_task'
/Users/Christopher/.rbenv/versions/2.0.0-p0/lib/ruby/2.0.0/rake/application.rb:101:in `block (2 levels) in top_level'
/Users/Christopher/.rbenv/versions/2.0.0-p0/lib/ruby/2.0.0/rake/application.rb:101:in `each'
/Users/Christopher/.rbenv/versions/2.0.0-p0/lib/ruby/2.0.0/rake/application.rb:101:in `block in top_level'
/Users/Christopher/.rbenv/versions/2.0.0-p0/lib/ruby/2.0.0/rake/application.rb:110:in `run_with_threads'
/Users/Christopher/.rbenv/versions/2.0.0-p0/lib/ruby/2.0.0/rake/application.rb:95:in `top_level'
/Users/Christopher/.rbenv/versions/2.0.0-p0/lib/ruby/2.0.0/rake/application.rb:73:in `block in run'
/Users/Christopher/.rbenv/versions/2.0.0-p0/lib/ruby/2.0.0/rake/application.rb:160:in `standard_exception_handling'
/Users/Christopher/.rbenv/versions/2.0.0-p0/lib/ruby/2.0.0/rake/application.rb:70:in `run'
/Users/Christopher/.rbenv/versions/2.0.0-p0/bin/rake:37:in `<main>'
Any ideas as to what I'm doing wrong?
Related
I'm trying to install backlogs module on my Redmine server, exactly following this guide: https://backlogs.github.io/www/en/installation.html
Though, that is what happens:
root#tannenfels:/var/www/redmine# bundle exec rake redmine:backlogs:install --trace
rake aborted!
Don't know how to build task 'redmine:backlogs:install' (see --tasks)
/var/www/redmine/.gem/ruby/2.3.0/gems/rake-12.3.1/lib/rake/task_manager.rb:59:in `[]'
/var/www/redmine/.gem/ruby/2.3.0/gems/rake-12.3.1/lib/rake/application.rb:159:in `invoke_task '
/var/www/redmine/.gem/ruby/2.3.0/gems/rake-12.3.1/lib/rake/application.rb:116:in `block (2 le vels) in top_level'
/var/www/redmine/.gem/ruby/2.3.0/gems/rake-12.3.1/lib/rake/application.rb:116:in `each'
/var/www/redmine/.gem/ruby/2.3.0/gems/rake-12.3.1/lib/rake/application.rb:116:in `block in to p_level'
/var/www/redmine/.gem/ruby/2.3.0/gems/rake-12.3.1/lib/rake/application.rb:125:in `run_with_th reads'
/var/www/redmine/.gem/ruby/2.3.0/gems/rake-12.3.1/lib/rake/application.rb:110:in `top_level'
/var/www/redmine/.gem/ruby/2.3.0/gems/rake-12.3.1/lib/rake/application.rb:83:in `block in run '
/var/www/redmine/.gem/ruby/2.3.0/gems/rake-12.3.1/lib/rake/application.rb:186:in `standard_ex ception_handling'
/var/www/redmine/.gem/ruby/2.3.0/gems/rake-12.3.1/lib/rake/application.rb:80:in `run'
/var/www/redmine/.gem/ruby/2.3.0/gems/rake-12.3.1/exe/rake:27:in `<top (required)>'
/var/www/redmine/.gem/ruby/2.3.0/bin/rake:23:in `load'
/var/www/redmine/.gem/ruby/2.3.0/bin/rake:23:in `<main>'
All dependencies seem to be resolved, and module tar.gz archive placed in right place. What I am doing wrong?
I've spent way too much time debugging this, and I have no idea what's going on. "cap production deploy" worked fine this morning, and now it just throws an error. Google has not been of much help so far, surprisingly. Nothing has changed in the code base that I know of:
➜ sesac-mm-matching git:(deploy) cap production deploy --trace
** Invoke production (first_time)
** Execute production
cap aborted!
NoMethodError: undefined method `already_invoked' for <Rake::Task load:defaults => []>:Rake::Task
/Users/***/.rvm/gems/ruby-2.3.0#global/gems/capistrano-3.6.0/lib/capistrano/dsl.rb:16:in `invoke'
/Users/***/.rvm/gems/ruby-2.3.0#global/gems/capistrano-3.6.0/lib/capistrano/setup.rb:24:in `block (2 levels) in <top (required)>'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/task.rb:240:in `block in execute'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `each'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `execute'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/Users/***/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/task.rb:172:in `invoke_with_call_chain'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/task.rb:165:in `invoke'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/application.rb:150:in `invoke_task'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `each'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `block in top_level'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/application.rb:115:in `run_with_threads'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/application.rb:100:in `top_level'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/application.rb:78:in `block in run'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/application.rb:176:in `standard_exception_handling'
/Users/***/.rvm/gems/ruby-2.3.0/gems/rake-10.5.0/lib/rake/application.rb:75:in `run'
/Users/***/.rvm/gems/ruby-2.3.0#global/gems/capistrano-3.6.0/lib/capistrano/application.rb:14:in `run'
/Users/***/.rvm/gems/ruby-2.3.0#global/gems/capistrano-3.6.0/bin/cap:3:in `<top (required)>'
/Users/***/.rvm/gems/ruby-2.3.0/bin/cap:23:in `load'
/Users/***/.rvm/gems/ruby-2.3.0/bin/cap:23:in `<main>'
/Users/***/.rvm/gems/ruby-2.3.0/bin/ruby_executable_hooks:15:in `eval'
/Users/***/.rvm/gems/ruby-2.3.0/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => production
Is anyone able provide some direction?
Yes, it looks like you've found a bug in the newly-released Capistrano 3.6.0. Please report the bug here: https://github.com/capistrano/capistrano/issues
The underlying problem is that Capistrano 3.6.0 is (mistakenly) incompatible with Rake < 11.0.0.
In the meantime, you can work around this issue by upgrading Rake to version 11.0.0 or higher with gem install rake or bundle update rake (depending on whether you use bundle exec for Capistrano or not).
If you are unable to upgrade Rake, downgrade Capistrano to version 3.5.0 until the bug has been fixed.
Update: Capistrano 3.6.1 has been released and restores compatibility with Rake < 11.0.0.
I'm learning rails and going step by step with lynda video series.
I tried rake . It gives following error.
$ rake generate migration DoNothingYet
rake aborted!
Don't know how to build task 'generate'
I used --trace to find the problem. However, it doesn't point the error.
$ rake generate migration DoNothingYet --trace
rake aborted!
Don't know how to build task 'generate'
/Users/boss/.rbenv/versions/2.2.2/lib/ruby/2.2.0/rake/task_manager.rb:62:in `[]'
/Users/boss/.rbenv/versions/2.2.2/lib/ruby/2.2.0/rake/application.rb:149:in `invoke_task'
/Users/boss/.rbenv/versions/2.2.2/lib/ruby/2.2.0/rake/application.rb:106:in `block (2 levels) in top_level'
/Users/boss/.rbenv/versions/2.2.2/lib/ruby/2.2.0/rake/application.rb:106:in `each'
/Users/boss/.rbenv/versions/2.2.2/lib/ruby/2.2.0/rake/application.rb:106:in `block in top_level'
/Users/boss/.rbenv/versions/2.2.2/lib/ruby/2.2.0/rake/application.rb:115:in `run_with_threads'
/Users/boss/.rbenv/versions/2.2.2/lib/ruby/2.2.0/rake/application.rb:100:in `top_level'
/Users/boss/.rbenv/versions/2.2.2/lib/ruby/2.2.0/rake/application.rb:78:in `block in run'
/Users/boss/.rbenv/versions/2.2.2/lib/ruby/2.2.0/rake/application.rb:176:in `standard_exception_handling'
/Users/boss/.rbenv/versions/2.2.2/lib/ruby/2.2.0/rake/application.rb:75:in `run'
/Users/boss/.rbenv/versions/2.2.2/bin/rake:33:in `<main>'
You should use rails command, not rake for this:
rails generate migration DoNothingYet
Good luck!
I'm various issues getting CocoaPods dependencies to work in RubyMotion. Firstly, if I add dependency 'JSONKit' to my Rakefile and then run rake it get's aborted with a can't convert Pathname into String error. rake --trace then produces the following output:
** Invoke default (first_time)
** Invoke simulator (first_time)
** Invoke build:simulator (first_time)
** Execute build:simulator
/usr/bin/gen_bridge_metadata --format complete --no-64-bit --cflags "-I. -I." JSONKit.h -o "JSONKit.bridgesupport"
invalid option: --no-64-bit
Usage: gen_bridge_metadata [options] <headers...>
Use the `-h' flag or consult gen_bridge_metadata(1) for help.
rake aborted!
Command failed with status (1): [/usr/bin/gen_bridge_metadata --format comp...]
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/file_utils.rb:53:in `block in create_shell_runner'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/file_utils.rb:45:in `call'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/file_utils.rb:45:in `sh'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/file_utils_ext.rb:39:in `sh'
/Library/RubyMotion/lib/motion/project/vendor.rb:93:in `block in build_static'
/Library/RubyMotion/lib/motion/project/vendor.rb:34:in `chdir'
/Library/RubyMotion/lib/motion/project/vendor.rb:34:in `build_static'
/Library/RubyMotion/lib/motion/project/vendor.rb:23:in `build'
/Library/RubyMotion/lib/motion/project/builder.rb:37:in `block in build'
/Library/RubyMotion/lib/motion/project/builder.rb:36:in `each'
/Library/RubyMotion/lib/motion/project/builder.rb:36:in `build'
/Library/RubyMotion/lib/motion/project/app.rb:50:in `build'
/Library/RubyMotion/lib/motion/project.rb:33:in `block (2 levels) in <top (required)>'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:205:in `call'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:205:in `block in execute'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:200:in `each'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:200:in `execute'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:158:in `block in invoke_with_call_chain'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:151:in `invoke_with_call_chain'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:176:in `block in invoke_prerequisites'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:174:in `each'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:174:in `invoke_prerequisites'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:157:in `block in invoke_with_call_chain'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:151:in `invoke_with_call_chain'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:176:in `block in invoke_prerequisites'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:174:in `each'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:174:in `invoke_prerequisites'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:157:in `block in invoke_with_call_chain'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:151:in `invoke_with_call_chain'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/task.rb:144:in `invoke'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/application.rb:116:in `invoke_task'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/application.rb:94:in `block (2 levels) in top_level'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/application.rb:94:in `each'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/application.rb:94:in `block in top_level'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/application.rb:133:in `standard_exception_handling'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/application.rb:88:in `top_level'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/application.rb:66:in `block in run'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/application.rb:133:in `standard_exception_handling'
/Users/xxxx/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rake/application.rb:63:in `run'
/Users/xxxx/.rbenv/versions/1.9.3-p194/bin/rake:32:in `<main>'
Tasks: TOP => default => simulator => build:simulator
The vendor directory in the project contains various JSONKit files.
Secondly, in another RubyMotion app, if I add dependency 'Nimbus' to my Rakefile and then run rake the app builds but errors out with uninitialized constant errors when I try to use anything Nimbus-related in my code and no vendor directory is created.
What is the problem in these two instances?
There are a couple issues at play here.
can't convert Pathname into String
Update: As of 5/7/12, you can just sudo motion update and this will be fixed
This error has to do with the fact that you're using Ruby 1.9. Though I don't see it explicitly stated in the documentation, the fact that the examples of setting this up refer to using sudo in the gem install commands means it's assumed you're running OS X's built-in ruby (1.8.7). If you switch your project to system ruby (add a .rbenv-version file with system in it). Alternatively, if you want to stick with 1.9, you can change line 22 of /Library/RubyMotion/lib/motion/project/vendor.rb to read:
App.info 'Build', #path.to_s
Once doing this, there's a good chance you'll then get an error like this:
ERROR! Building vendor project `./vendor/JSONKit' failed to create at least one `.a' library.`
You'll need to edit line 77 of that same file to read:
objs = Dir.glob('**/*.o') # Removed the leading "*/"
Then rake should finally work properly.
An issue has been filed on the motion-cocoapods repo regarding these issues: https://github.com/HipByte/motion-cocoapods/issues/1
Additionally, I just filed an official support ticket for this using motion support. (Remember, you paid money for this brand new product which includes support; use it!)
Nimbus
The problem here is that you're requiring the top-level cocoapod. Since it has "subspecs", you need to require those directly, so maybe dependency 'Nimbus/Core' instead. You can see a full list of them here (see the s.subspec entries)
The compilation error about the --no-64-bit flag is because of a but on RubyMotion on Snow Leopard. update /Library/RubyMotion/lib/motion/project/vendor.rb per https://gist.github.com/2597428
The bug has been confirmed by Laurent Sansonetti:
Hi,
Thanks for the report! The problem is that the --no-64-bit flag was
added in Lion and you appear to be running Snow Leopard. We will get
this fixed.
Laurent
I'm setting up a rakefile for a project, and I've defined some rake TestTasks. I ran a simple sanity test that does an assert_equal(1, 2) just to check the output, and, in addition to the usual failure output, I get this mess:
rake aborted!
Command failed with status (1): [/usr/bin/ruby -w -I"lib:." "/usr/lib/ruby/...]
/usr/lib/ruby/1.9.1/rake.rb:993:in `block in sh'
/usr/lib/ruby/1.9.1/rake.rb:1008:in `call'
/usr/lib/ruby/1.9.1/rake.rb:1008:in `sh'
/usr/lib/ruby/1.9.1/rake.rb:1092:in `sh'
/usr/lib/ruby/1.9.1/rake.rb:1027:in `ruby'
/usr/lib/ruby/1.9.1/rake.rb:1092:in `ruby'
/usr/lib/ruby/1.9.1/rake/testtask.rb:115:in `block (2 levels) in define'
/usr/lib/ruby/1.9.1/rake.rb:1110:in `verbose'
/usr/lib/ruby/1.9.1/rake/testtask.rb:100:in `block in define'
/usr/lib/ruby/1.9.1/rake.rb:634:in `call'
/usr/lib/ruby/1.9.1/rake.rb:634:in `block in execute'
/usr/lib/ruby/1.9.1/rake.rb:629:in `each'
/usr/lib/ruby/1.9.1/rake.rb:629:in `execute'
/usr/lib/ruby/1.9.1/rake.rb:595:in `block in invoke_with_call_chain'
/usr/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize'
/usr/lib/ruby/1.9.1/rake.rb:588:in `invoke_with_call_chain'
/usr/lib/ruby/1.9.1/rake.rb:605:in `block in invoke_prerequisites'
/usr/lib/ruby/1.9.1/rake.rb:602:in `each'
/usr/lib/ruby/1.9.1/rake.rb:602:in `invoke_prerequisites'
/usr/lib/ruby/1.9.1/rake.rb:594:in `block in invoke_with_call_chain'
/usr/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize'
/usr/lib/ruby/1.9.1/rake.rb:588:in `invoke_with_call_chain'
/usr/lib/ruby/1.9.1/rake.rb:581:in `invoke'
/usr/lib/ruby/1.9.1/rake.rb:2041:in `invoke_task'
/usr/lib/ruby/1.9.1/rake.rb:2019:in `block (2 levels) in top_level'
/usr/lib/ruby/1.9.1/rake.rb:2019:in `each'
/usr/lib/ruby/1.9.1/rake.rb:2019:in `block in top_level'
/usr/lib/ruby/1.9.1/rake.rb:2058:in `standard_exception_handling'
/usr/lib/ruby/1.9.1/rake.rb:2013:in `top_level'
/usr/lib/ruby/1.9.1/rake.rb:1992:in `run'
/usr/bin/rake:31:in `<main>'
How do I get rid of it? I don't want to have to scroll up past 20 lines of junk to see my test failures.
I had the same problem as you and solved it by updating rake: gem install rake
This updated from whatever I had to 0.8.7.
I'm running 1.9.2-p180 (OS X, installed with Homebrew) and was running tests on a newly created project (made with Hoe).
Rake shouldn't be returning a backtrace in this situation -- the error is with the external command, not rake's internals. I've sent a email to Jim Weirich regarding the following patch: https://gist.github.com/1003628
Rake normally does not show a backtrace unless you specify --trace. Perhaps you have configured Rake to always run in --trace mode?
By default, rake does not print out the stack trace if you get an error in the code that rake calls. You can get the stack trace by running with the --trace flag, but usually I'd just rather see it anyway. You can do that by putting Rake.application.options.trace = true into the rakefile.
If not, you might try setting Rake.application.options.trace = false in your Rakefile.
I still had unwanted stack traces in rake 0.8.7, updating to 0.9.2 finally helped for me (ruby 1.9.2p180 [i386-mingw32] on Win7 32bit).
Look in config/initializers/backtrace_silencers.rb
You should be able to add something like
Rails.backtrace_cleaner.add_silencer { |line| line =~ %r{/usr/lib/ruby/1.9.1/rake.rb} }