Skip to content
Browse files

don't clear the crontab during a deploy

  • Loading branch information...
1 parent bf8d1f9 commit 42fc19f669e07aa728434622b171a29653230ada @javan committed
Showing with 0 additions and 4 deletions.
  1. +0 −4 lib/whenever/capistrano.rb
View
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

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
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.

@jrochkind

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

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

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

Please sign in to comment.
Something went wrong with that request. Please try again.