[GTALUG] Crontab versioning

[David Collier-Brown]

On 04/05/18 09:10 AM, Alex Beamish via talk wrote:
> On Fri, May 4, 2018 at 8:11 AM, Jamon Camisso via talk 
> <talk at gtalug.org <mailto:talk at gtalug.org>> wrote:
>
>     On 2018-05-03 10:44 AM, Alex Beamish via talk wrote:
>     > I'm developing scripts that get run by crontab, so I'm in there
>     making
>     > updates fairly regularly. I would love to be able to document
>     the changes,
>     > so I'm wondering if there a usual and customary technique to version
>     > crontabs?
>

I've used RCS for lots of ad-hoc systems file tracking, and at least 
once replaced crontab with a script that added a check-in after calling 
the real crontab -e.  It could easily do a git commit && git push instead.

--dave


>
>     What are you changing in crontabs so much that you need versioning?
>
>
> I'm developing EDI scripts, and as development progresses, some of the 
> older scripts are being replaced by newer scripts. On occasion, there 
> are times when I need to disable a crontab job while I solve an issue.
>
> Having version control would be a great back-stop, and would also be 
> useful from a historical point of view. (Why did I disable that job 
> last Thursday? Where did the such and such script go?)
>
>     Shouldn't all the logic be in your scripts? Maybe I'm missing
>     something,
>     but it seems like needless complication to me.
>
>
> What to do and how to do it is in the scripts. How often to do it is 
> in the crontab.
>
>
>     > Ideally there would be some sort of hook around 'crontab -e',
>     but failing
>     > that, I'd have the output of 'crontab -l' (run regularly by
>     cron?) go to a
>     > versioned file. Plan B sounds a bit hokey to me.
>     If you do need to version things, you can just chuck a git repo under
>     /var/spool/cron/crontabs and ignore any files there you don't want
>     tracked.
>
>
> Under my system, that directory is owned by root, and I prefer not to 
> version anything as root; the code I'm developing is application code, 
> not system code.
>
> The solution I'm leaning towards is to have a shell script for 
> updating the crontab that would do something like
> 1. pushd $local_crontab_directory
> 2. crontab -e
> 3. crontab -l >crontab.$username
> 4. git diff crontab.$username
>
> If there were changes revealed by the 'git diff', and if I felt they 
> were significant, I could do a git commit, followed by a popd.
>
> Thanks for your questions -- they helped me clarify my understanding 
> of the problem and a possible solution.
>
> -- 
> Alex Beamish
>
> Software Developer / https://ca.linkedin.com/in/alex-beamish-5111ba3
> Speaker Wrangler, Toronto Perlmongers / http://to.pm.org/
> Baritone, Board Member, Toronto Northern Lights, 2013 Champions / 
> www.northernlightschorus.com <http://www.northernlightschorus.com>
> Certified Contest Administrator, Barbershop Harmony Society / 
> www.barbershop.org <http://www.barbershop.org>
>
>
>
> ---
> Talk Mailing List
> talk at gtalug.org
> https://gtalug.org/mailman/listinfo/talk


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20180504/07a8e3be/attachment.html>