Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Capistrano V3 Support #387

Merged
merged 8 commits into from Dec 8, 2013
Merged

Capistrano V3 Support #387

merged 8 commits into from Dec 8, 2013

Conversation

phallstrom
Copy link
Contributor

@phallstrom phallstrom commented Sep 21, 2013

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.

@kirs
Copy link

@kirs kirs commented Sep 22, 2013

I use capistrano/rbenv and SSHKit.config.command_map[:whenever] = "bundle exec whenever" is not working.

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.

@kirs
Copy link

@kirs kirs commented Sep 22, 2013

Thank you for adding cap3 support, it saved me a lot of time 👍

@javan
Copy link
Owner

@javan javan commented Sep 22, 2013

Thanks so much for kicking this off!

Is V3 1.9 only? If not, I think we should stick with 1.8 style procs.

@kirs
Copy link

@kirs kirs commented Sep 23, 2013

Yes, it's 1.9 only.

Kir Shatrov
+7 (929) 631-46-35

On Sunday, September 22, 2013 at 7:34 PM, Javan Makhmali wrote:

Thanks so much for kicking this off!
Is V3 1.9 only? If not, I think we should stick 1.8 style procs.


Reply to this email directly or view it on GitHub (#387 (comment)).

@kirs
Copy link

@kirs kirs commented Sep 30, 2013

@javan could you merge it, please?

@daniel-g
Copy link

@daniel-g daniel-g commented Sep 30, 2013

+1 to this, I need it for my next deploy :)

@phallstrom
Copy link
Contributor Author

@phallstrom phallstrom commented Sep 30, 2013

@daniel-g @kirs Not ideal I know, but you can use my branch right now...

https://github.com/phallstrom/whenever

@daniel-g
Copy link

@daniel-g daniel-g commented Sep 30, 2013

I am :) heh. I will let you know if anything wrong happens.

@wontruefree
Copy link

@wontruefree wontruefree commented Oct 2, 2013

+1 this would be awesome.

@wontruefree
Copy link

@wontruefree wontruefree commented Oct 2, 2013

@kirs I use the the rbenv bins and add another command it

set :rbenv_map_bins, fetch(:rbenv_map_bins) << "whenever"

@kirs
Copy link

@kirs kirs commented Oct 3, 2013

@Javajax cool trick, I'll use it!

@wontruefree
Copy link

@wontruefree wontruefree commented Oct 3, 2013

Is there anything holding up this pull request?

@daniel-g
Copy link

@daniel-g daniel-g commented Oct 3, 2013

It is working for me :) BTW.

@wontruefree
Copy link

@wontruefree wontruefree commented Oct 3, 2013

Its works for me as well.

@seejohnrun
Copy link

@seejohnrun seejohnrun commented Oct 19, 2013

+1 very helpful

@Bazai
Copy link

@Bazai Bazai commented Oct 20, 2013

👍 Helped a lot

…nd let it determine what version of Capistrano gem is being used
@phallstrom
Copy link
Contributor Author

@phallstrom phallstrom commented Oct 21, 2013

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.

@kirs
Copy link

@kirs kirs commented Oct 21, 2013

@phallstrom awesome! I was thinking about that too :)

@jarthod
Copy link

@jarthod jarthod commented Oct 26, 2013

+1

@ghost
Copy link

@ghost ghost commented Oct 29, 2013

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

@phallstrom
Copy link
Contributor Author

@phallstrom phallstrom commented Oct 31, 2013

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'
Copy link
Owner

@javan javan Oct 31, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe require_relative is 1.9+, no?

Copy link

@pencil pencil Nov 1, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is. But Ruby 1.8.7 was retired earlier this year, so this should not be much of a problem...

Copy link
Owner

@javan javan Nov 1, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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__)
Copy link
Owner

@javan javan Oct 31, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/?

Copy link
Contributor Author

@phallstrom phallstrom Oct 31, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's necessary, but it's pretty common.

Copy link

@dmarkow dmarkow Oct 31, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the pattern Capistrano's own libraries use (e.g. https://github.com/capistrano/rvm/blob/master/lib/capistrano/tasks/rvm.rake)

Copy link

@kirs kirs Oct 31, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me as a Capistrano maintainer, whenever/capistrano/v2/ and whenever/capistrano/v3/ look way better.

Copy link
Contributor Author

@phallstrom phallstrom Oct 31, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to change it if there's consensus from the folks that matter (ie... not me :)

Copy link
Owner

@javan javan Oct 31, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could symlink a file from /tasks to whenever/capistrano/v3/tasks perhaps?

@kennym
Copy link

@kennym kennym commented Nov 3, 2013

+1 towards seeing this feature merged!

@ForestHeart
Copy link

@ForestHeart ForestHeart commented Nov 12, 2013

+1

@tisba
Copy link

@tisba tisba commented Nov 14, 2013

Using https://github.com/phallstrom/whenever I get undefined method 'to_sym' for nil:NilClass when running cap production whenever:update_crontab (cap production deploy results in the same issue).

In the top of my config/deploy.rb I have:

set :whenever_environment, ->{ stage }
set :whenever_role, -> { :app }
require "whenever/capistrano"

First I thought it has something to do with whenever_role not being specified (this is why I added it). But now I'm a little bit lost… What am I missing?

Here is the complete error:

    $ cap production whenever:update_crontab
    cap aborted!
    undefined method `to_sym' for nil:NilClass
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/configuration/servers/role_filter.rb:25:in `each'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/configuration/servers/role_filter.rb:25:in `flat_map'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/configuration/servers/role_filter.rb:25:in `required'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/configuration/servers/role_filter.rb:15:in `roles'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/configuration/servers/role_filter.rb:11:in `for'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/configuration/servers.rb:45:in `fetch_roles'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/configuration/servers.rb:18:in `roles_for'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/configuration.rb:45:in `roles_for'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/dsl/env.rb:43:in `roles'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/bundler/gems/whenever-83be4c51352c/lib/whenever/tasks/whenever.rake:4:in `block (2 levels) in <top (required)>'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/lib/capistrano/application.rb:12:in `run'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/gems/capistrano-3.0.1/bin/cap:3:in `<top (required)>'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/bin/cap:23:in `load'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/bin/cap:23:in `<main>'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/bin/ruby_executable_hooks:15:in `eval'
    /Users/basti/.rvm/gems/ruby-2.0.0-p247/bin/ruby_executable_hooks:15:in `<main>'
    Tasks: TOP => whenever:update_crontab
    (See full trace by running task with --trace)

@tisba
Copy link

@tisba tisba commented Nov 14, 2013

Nevermind, it's whenever_roles (plural). But it seems that the defaulting to :db isn't working anymore.

@tisba
Copy link

@tisba tisba commented Nov 14, 2013

Sorry for the noise :-/ The deployment now completes without an error, but no crontab get's written:

2.0.0-p247 master ego ➜ cap production whenever:update_crontab
 INFO [0876fccd] Running /usr/bin/env bundle exec whenever  on app.example.com
 INFO [0876fccd] Finished in 0.500 seconds with exit status 0 (successful).

Maybe this has something to do with the defaults not getting loaded and therefor the whenever_update_flags are missing.

@phallstrom
Copy link
Contributor Author

@phallstrom phallstrom commented Nov 14, 2013

@tisba You need to require "whenever/capistrano" in Capfile, before you do any variable setting. I have mine in Capfile, and have one setting in config/deploy.rb (set :whenever_identifier, ->{ "#{fetch(:application)}_#{fetch(:stage)}" } and things work...

$ bundle exec cap staging whenever:update_crontab
DEBUG [3db6afc6] Running /usr/bin/env if test ! -d /home/deploy/apps/xxx/current; then echo "Directory does not exist '/home/deploy/apps/xxx/current'" 1>&2; false; fi on xxx
DEBUG [3db6afc6] Command: if test ! -d /home/deploy/apps/xxx/current; then echo "Directory does not exist '/home/deploy/apps/xxx/current'" 1>&2; false; fi
DEBUG [3db6afc6] Finished in 0.898 seconds with exit status 0 (successful).
 INFO [acabdc4b] Running /usr/bin/env bundle exec whenever --update-crontab xxx_staging --set environment=staging on xxx
DEBUG [acabdc4b] Command: cd /home/deploy/apps/xxx/current && /usr/bin/env bundle exec whenever --update-crontab xxx_staging --set environment=staging
DEBUG [acabdc4b]        [write] crontab file updated
 INFO [acabdc4b] Finished in 3.534 seconds with exit status 0 (successful).

@tisba
Copy link

@tisba tisba commented Nov 14, 2013

@phallstrom if I don't specify :whenever_roles I get the undefined method 'to_sym' for nil:NilClass error. It doesn't matter, if I set the variables before or after the require in config/deploy.rb (they should be lazy evaluated anyway). Like I said, somehow the defaults aren't loaded properly (I assume).

@phallstrom
Copy link
Contributor Author

@phallstrom phallstrom commented Nov 14, 2013

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" ?

@tisba
Copy link

@tisba tisba commented Nov 15, 2013

@phallstrom bundle exec doesn't change anything.

But I found out, that if I require 'whenever/capistrano' before require 'capistrano/bundler' everyones (capistrano-bundler and whenever) defaults are getting loaded properly. Unfortunately I don't have time right now to investigate this further, but maybe you can reproduce it now.

@phallstrom
Copy link
Contributor Author

@phallstrom phallstrom commented Nov 15, 2013

@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

@tisba
Copy link

@tisba tisba commented Nov 19, 2013

My Capfile looks like this:

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 }

config/deploy.rb has no additional requires.

@shaneog
Copy link

@shaneog shaneog commented Nov 29, 2013

👍

1 similar comment
@hidakatsuya
Copy link

@hidakatsuya hidakatsuya commented Nov 29, 2013

👍

javan added a commit that referenced this issue Dec 8, 2013
@javan javan merged commit 6f493b5 into javan:master Dec 8, 2013
1 check passed
@phallstrom
Copy link
Contributor Author

@phallstrom phallstrom commented Dec 9, 2013

Thanks @javan! Eta for a gem release?

@javan
Copy link
Owner

@javan javan commented Dec 9, 2013

Thank you! Gem release this week for sure.

@trooster
Copy link

@trooster trooster commented Dec 11, 2013

👍

1 similar comment
@mryoshio
Copy link

@mryoshio mryoshio commented Dec 12, 2013

👍

@javan
Copy link
Owner

@javan javan commented Dec 16, 2013

@phallstrom I moved the files around some. Mind reviewing? I'll release right after.

@phallstrom
Copy link
Contributor Author

@phallstrom phallstrom commented Dec 16, 2013

@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:

INFO [62964482] Running /usr/bin/env bundle exec whenever --update-crontab xxxx_production --set environment=production on xxxx
DEBUG [62964482] Command: cd /home/deploy/apps/xxxx/releases/20131216172845 && /usr/bin/env bundle exec whenever --update-crontab xxxx_production --set environment=production
DEBUG [62964482]        [write] crontab file updated
 INFO [62964482] Finished in 2.645 seconds with exit status 0 (successful).

@javan
Copy link
Owner

@javan javan commented Dec 18, 2013

Released! Thanks for your patience.

@phallstrom
Copy link
Contributor Author

@phallstrom phallstrom commented Dec 18, 2013

@javan Wahoo! Whenever has made my life a lot easier. Thanks!

@jarthod
Copy link

@jarthod jarthod commented Dec 18, 2013

Thanks ! I can finally switch back to the gem.

@hidakatsuya
Copy link

@hidakatsuya hidakatsuya commented Dec 19, 2013

👍 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet