Whenever with capistrano should use symlinked `/current/` instead of `/app_revision/` folder in crontab
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 8.9k
- Forks
- 715
- PR merge metrics
- No merged PRs in 30d
Description
Consider the following : I have two roles in capistrano, :worker, and :scheduler
My :scheduler role was meant for the machine whose crontab will be updated with whenever.
My :worker role is meant for processing background jobs
It turns out to save costs, I decided my scheduler machine could also be a worker to process async jobs. Now two scenarios and the second one is buggy :
- When I deploy to the
:schedulerRole, it will deploy to my whenever-enabled machine and update the crontab, all good. - When I deploy to the
:workerRole, it will still deploy to my whenever-enabled machine (as it is a worker at the same time) but it WON'T update the crontab (since crontab update is only affiliated to:scheduler. Now what happens is that- Not only will whenever use an old app version but
- after
keep_releasesdeployments, the folder that was referenced by the crontab will no longer exist, causes silent crashes of the scheduler (unless email warnings are enabled to report cron failures)
In order to fix this I would suggest that crontab always uses the symlink /current used by capistrano to maintain the active version. What about it ?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how whenever generates crontab entries during Capistrano deployments, especially when a machine has both the worker and scheduler roles. Verify the shared scheduler/worker scenario across releases and keep_releases; done means cron entries use the stable /current symlink and continue running after worker-only deployments and old releases are removed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- devops
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100