javan / javan/whenever

cron jobs are overwritten for other environments on each deploy

Open
#544 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bugfix capistrano
Dominant language
Ruby
Stars
8.9k
Forks
715
PR merge metrics
No merged PRs in 30d

Description

I've been using whenever for years, mostly under capistrano 2, without a hitch. It's been a really great experience - thank you!

I'm deploying a Rails app with capistrano 3 right now, and I'm really confused about how to get multiple environments on a single server to play well with each other. I have two environments, staging and production, on one server, and they keep clobbering each other.

  • If I deploy staging, then all of the cronjobs are removed and replaced with jobs referencing the staging release path and environment. All of the production jobs are gone.
  • If I deploy production, then all of the cronjobs are removed and replaced with jobs referencing the production release path and environment. All of the staging jobs are gone.
  • If I do a case statement in schedule.rb on @environment, and only have jobs set for a when 'production' situation, then when staging is deployed it completely clears the cronjobs. All of the jobs are gone.

I need to get to either of these two situations:

  • Have two sets of jobs (one for staging and one for production) that each persist through either environment's deploy (so, in my example at the bottom, there would be two jobs listed - one for the staging release and one for the production release)
  • One set of jobs (just for production) that persists through either environment's deploy (so, the staging deploy should not remove it)

Can you explain how this is done?
I've included my current configuration, below, in case it's helpful.

Capfile

require 'whenever/capistrano'

config/deploy/production.rb

server '1.2.3.4', user: 'username', roles: %w{web app}
set :branch, 'master'
set :deploy_to, '/home/username/production'
set :rails_env, 'production'
set :stage, :production
set :whenever_environment, -> { fetch(:stage) }
set :whenever_identifier, -> { "#{fetch(:application)}_#{fetch(:stage)}" }

config/deploy/staging.rb

server '1.2.3.4', user: 'username', roles: %w{web app}
set :branch, 'staging'
set :deploy_to, '/home/username/staging'
set :rails_env, 'staging'
set :stage, :staging
set :whenever_environment, -> { fetch(:stage) }
set :whenever_identifier, -> { "#{fetch(:application)}_#{fetch(:stage)}" }

config/schedule.rb

set :output, '/log/cron.log'
every 10.minutes do
  runner 'ModelName.method_name'
end

the resulting cronjob after a staging deploy

0,10,20,30,40,50 * * * * /bin/bash -l -c 'cd /home/username/staging/releases/20150317012814 && script/rails runner -e staging '\''ModelName.method_name'\'' >> /log/cron.log 2>&1'

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Capfile and the deployment settings in config/deploy/production.rb and config/deploy/staging.rb, then trace the whenever/capistrano entry point and config/schedule.rb. Confirm how each deploy updates the shared crontab and how whenever_identifier is applied. Done means staging and production jobs coexist or a production-only job survives staging deploys, as requested.

Written by the indexing model from the issue text.

Assessment

Tech stack
rails, ruby
Domain
devops
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.