Capistrano V3 Support #387
Conversation
|
I use capistrano/rbenv and Here is a workaround: SSHKit.config.command_map[:whenever] = "RBENV_ROOT=~/.rbenv RBENV_VERSION=2.0.0-p247 ~/.rbenv/bin/rbenv exec bundle exec whenever"This line doesn't look well and it's seems like a problem in SSHKit design. |
|
Thank you for adding cap3 support, it saved me a lot of time 👍 |
|
Thanks so much for kicking this off! Is V3 1.9 only? If not, I think we should stick with 1.8 style procs. |
|
Yes, it's 1.9 only. Kir Shatrov On Sunday, September 22, 2013 at 7:34 PM, Javan Makhmali wrote:
|
|
@javan could you merge it, please? |
|
+1 to this, I need it for my next deploy :) |
|
I am :) heh. I will let you know if anything wrong happens. |
|
+1 this would be awesome. |
|
@kirs I use the the rbenv bins and add another command it set :rbenv_map_bins, fetch(:rbenv_map_bins) << "whenever" |
|
@Javajax cool trick, I'll use it! |
|
Is there anything holding up this pull request? |
|
It is working for me :) BTW. |
|
Its works for me as well. |
|
+1 very helpful |
|
👍 Helped a lot |
…nd let it determine what version of Capistrano gem is being used
|
I tweaked the pull request so that it's no longer necessary to load 'whenever/capistrano3'. Just load 'whenever/capistrano' and that file will determine what version of Capistrano is being run and then load the appropriate code. |
|
@phallstrom awesome! I was thinking about that too :) |
|
+1 |
|
I have a very simple use case, so this might not apply to most people but I've removed the need for this gem in Capistrano 3 with the following task: desc "Update crontab with whenever"
task :update_crontab do
on roles(:all) do
within release_path do
execute :bundle, :exec, "whenever --update-crontab #{fetch(:application)}"
end
end
end |
…use bundle exec. this should avoid the sshkit mapping issue
|
I've added some code based on some work I/others did for sidekiq/capistrano3. Made it work with capistrano 2 and a work around for the SSHKit mapping issue so that 'bundle exec whenever' will work by default. @javan Any idea if/when this will get integrated? |
| if defined?(Capistrano::VERSION) && Gem::Version.new(Capistrano::VERSION).release >= Gem::Version.new('3.0.0') | ||
| load File.expand_path("../tasks/whenever.rake", __FILE__) | ||
| else | ||
| require_relative 'capistrano2' |
There was a problem hiding this comment.
I believe require_relative is 1.9+, no?
There was a problem hiding this comment.
Yes, it is. But Ruby 1.8.7 was retired earlier this year, so this should not be much of a problem...
There was a problem hiding this comment.
@pencil Whenever supports 1.8.7. @phallstrom Thanks for fixing.
| # If anything goes wrong, undo. | ||
| after "deploy:rollback", "whenever:update_crontab" | ||
| if defined?(Capistrano::VERSION) && Gem::Version.new(Capistrano::VERSION).release >= Gem::Version.new('3.0.0') | ||
| load File.expand_path("../tasks/whenever.rake", __FILE__) |
There was a problem hiding this comment.
How important is it that this file live in lib/tasks?
It would be nice to reorganize all the cap related files. Maybe whenever/capistrano/v2/ and whenever/capistrano/v3/?
There was a problem hiding this comment.
I don't think it's necessary, but it's pretty common.
There was a problem hiding this comment.
It's the pattern Capistrano's own libraries use (e.g. https://github.com/capistrano/rvm/blob/master/lib/capistrano/tasks/rvm.rake)
There was a problem hiding this comment.
For me as a Capistrano maintainer, whenever/capistrano/v2/ and whenever/capistrano/v3/ look way better.
There was a problem hiding this comment.
I'm happy to change it if there's consensus from the folks that matter (ie... not me :)
There was a problem hiding this comment.
Could symlink a file from /tasks to whenever/capistrano/v3/tasks perhaps?
|
+1 towards seeing this feature merged! |
|
+1 |
|
Using https://github.com/phallstrom/whenever I get In the top of my set :whenever_environment, ->{ stage }
set :whenever_role, -> { :app }
require "whenever/capistrano"First I thought it has something to do with Here is the complete error: |
|
Nevermind, it's |
|
Sorry for the noise :-/ The deployment now completes without an error, but no crontab get's written: Maybe this has something to do with the defaults not getting loaded and therefor the |
|
@tisba You need to |
|
@phallstrom if I don't specify |
|
Strange. I think you're right that the defaults aren't being loaded for you, but I'm not sure why. Does anything change if you "bundle exec" ? |
|
@phallstrom But I found out, that if I |
|
@tisba Strange. I'm doing the reverse. Are you loading them in Capfile or config/deploy.rb? My capfile looks like this: https://gist.github.com/phallstrom/5de6f57634be563a2768 |
|
My require 'capistrano/setup'
require 'capistrano/deploy'
require 'whenever/capistrano'
require 'capistrano/bundler'
require 'capistrano/rails/assets'
require 'capistrano/rails/migrations'
Dir.glob('lib/capistrano/tasks/*.cap').each { |r| import r }
|
|
👍 |
1 similar comment
|
👍 |
|
Thanks @javan! Eta for a gem release? |
|
Thank you! Gem release this week for sure. |
|
👍 |
1 similar comment
|
👍 |
|
@phallstrom I moved the files around some. Mind reviewing? I'll release right after. |
|
@javan Looks good. I switched my app to your github branch and deployed. No errors, and I'm seeing what I'd hope to see in the deploy output: |
|
Released! Thanks for your patience. |
|
@javan Wahoo! Whenever has made my life a lot easier. Thanks! |
|
Thanks ! I can finally switch back to the gem. |
|
👍 👍 |
I've added support for capistrano version 3 and updated the README. I've tested it a little bit and everything seems to work (deploying and rolling back). I did my best to model it after the other V3 modules that the capistrano team is putting out.
One change that's worth mentioning is that the "on_rollback" functionality is gone in V3. I'm not sure how it's being handled now (I'm assuming they handle it by calling the rollback rake tasks) but that changes some of the code you had.
Nothing for V2 has been touched. Only new files so this should have zero impact on existing installations.