Permalink
Browse files

don't clear the crontab during a deploy

  • Loading branch information...
javan committed Aug 26, 2012
1 parent bf8d1f9 commit 42fc19f669e07aa728434622b171a29653230ada
Showing with 0 additions and 4 deletions.
  1. +0 −4 lib/whenever/capistrano.rb
@@ -1,12 +1,8 @@
require "whenever/capistrano/recipes"
Capistrano::Configuration.instance(:must_exist).load do
-
- # Disable cron jobs at the begining of a deploy.
- after "deploy:update_code", "whenever:clear_crontab"
# Write the new cron jobs near the end.
before "deploy:finalize_update", "whenever:update_crontab"
# If anything goes wrong, undo.
after "deploy:rollback", "whenever:update_crontab"
-
end

7 comments on commit 42fc19f

@jrochkind

This comment has been minimized.

Show comment
Hide comment
@jrochkind

jrochkind Sep 27, 2012

just curious, why not?

I had my own capistrano recipes written to do whenever (since I needed too many things different from default, it seemed easier), but I based it on what you had. I noticed my recipe wasn't working quite right, with the clear_crontab for some reason firing too late and always resulting in a cleared crontab.

So I went to the source to see if I was doing different than you -- and see you've removed the clear entirely! Can you give background on what it was originally intended to do, and why you think it's not needed anymore? thanks!

just curious, why not?

I had my own capistrano recipes written to do whenever (since I needed too many things different from default, it seemed easier), but I based it on what you had. I noticed my recipe wasn't working quite right, with the clear_crontab for some reason firing too late and always resulting in a cleared crontab.

So I went to the source to see if I was doing different than you -- and see you've removed the clear entirely! Can you give background on what it was originally intended to do, and why you think it's not needed anymore? thanks!

@javan

This comment has been minimized.

Show comment
Hide comment
@javan

javan Sep 27, 2012

Owner

Way back when, it seemed like a good idea to "pause" the cron jobs while deploying so we'd clear them at the beginning and then write them again at the end of a deploy. At some point, the cap hooks get messed up so that whenever:clear_crontab was happening last. No good.

In the end, it's simpler to avoid clearing altogether.

Owner

javan replied Sep 27, 2012

Way back when, it seemed like a good idea to "pause" the cron jobs while deploying so we'd clear them at the beginning and then write them again at the end of a deploy. At some point, the cap hooks get messed up so that whenever:clear_crontab was happening last. No good.

In the end, it's simpler to avoid clearing altogether.

@jrochkind

This comment has been minimized.

Show comment
Hide comment
@jrochkind

jrochkind Sep 27, 2012

okay, thanks! Yep, that's exactly the problem I had in my 'fork' of yours, clear_crontab happening last. So I went to check with the mothership, and found this. Ain't github grand. Okay, if not clearing is good enough for you, it's good enough for me.

Incidentally, the reason I have my own 'fork' of your cap tasks: Not only do I need different cron jobs on different 'roles' (I see you added a feature for that since I 'forked' my own local version, sweet) -- but I need different cap whenever parameters on different 'roles' too! Like one cronjob needs to run under jruby so needs parameters set as that, while other cronjobs run under standard mri so need different flags. So i forked my own set of recipes to do exactly what I needed, based on what you started with. But of course the disadvantage is now I don't take advantage of your upgrades and fixes, as in this case. If you ever figure out a way to accomodate my use case too, that'd be sweet! But I couldn't figure out any good way to do that in generic cap tasks distro'd with whenever, or I'd send a pull request.

okay, thanks! Yep, that's exactly the problem I had in my 'fork' of yours, clear_crontab happening last. So I went to check with the mothership, and found this. Ain't github grand. Okay, if not clearing is good enough for you, it's good enough for me.

Incidentally, the reason I have my own 'fork' of your cap tasks: Not only do I need different cron jobs on different 'roles' (I see you added a feature for that since I 'forked' my own local version, sweet) -- but I need different cap whenever parameters on different 'roles' too! Like one cronjob needs to run under jruby so needs parameters set as that, while other cronjobs run under standard mri so need different flags. So i forked my own set of recipes to do exactly what I needed, based on what you started with. But of course the disadvantage is now I don't take advantage of your upgrades and fixes, as in this case. If you ever figure out a way to accomodate my use case too, that'd be sweet! But I couldn't figure out any good way to do that in generic cap tasks distro'd with whenever, or I'd send a pull request.

@sjf-control

This comment has been minimized.

Show comment
Hide comment
@sjf-control

sjf-control Nov 5, 2012

I seems one of the issues with clear_crontab is that it references "latest_release". This symbol initializes ":releases", which is based upon the current contents of the releases folder, and once set, these symbols are never updated. So if clear_crontab is called before the new release folder is created (or at least named), the ultimate "current" symlink will be pointed at the old release instead of the new one.

This problem can be fixed by changing the "(fetch :latest_release)" line in clear_crontab to "(fetch :current_path)", which does not have the unintended side-effects.

These symbols and how they are initialized can be found in capistrano/recipes/deploy.rb

I seems one of the issues with clear_crontab is that it references "latest_release". This symbol initializes ":releases", which is based upon the current contents of the releases folder, and once set, these symbols are never updated. So if clear_crontab is called before the new release folder is created (or at least named), the ultimate "current" symlink will be pointed at the old release instead of the new one.

This problem can be fixed by changing the "(fetch :latest_release)" line in clear_crontab to "(fetch :current_path)", which does not have the unintended side-effects.

These symbols and how they are initialized can be found in capistrano/recipes/deploy.rb

@jrochkind

This comment has been minimized.

Show comment
Hide comment
@jrochkind

jrochkind Nov 5, 2012

@lserman

This comment has been minimized.

Show comment
Hide comment
@lserman

lserman Aug 1, 2013

What is the best way to do this, then? I don't want to manually clear my crontab everytime I deploy. Is there a safe way to automatically refresh my crontab in capistrano?

What is the best way to do this, then? I don't want to manually clear my crontab everytime I deploy. Is there a safe way to automatically refresh my crontab in capistrano?

@javan

This comment has been minimized.

Show comment
Hide comment
@javan

javan Aug 1, 2013

Owner

The default Cap recipe executes whenever --update-crontab, which updates your crontab entries, not append to them. Is that the refresh you're looking for?

Owner

javan replied Aug 1, 2013

The default Cap recipe executes whenever --update-crontab, which updates your crontab entries, not append to them. Is that the refresh you're looking for?

Please sign in to comment.