Mailto

[adamcagle]

Support Sending Email When And Only When Script Errors

• Changes the command generated by cron_rscript() so that stdout & stderr generate an output when and only when the R script errors
• If the R script errors, cron will send an email to the address specified by MAILTO in crontab
• Logs are still generated as before with no changes to the cron_rscript() API
• New convention adopted via deparse_crontab() which always places cronR jobs at the bottom of the crontab (rather than at the beginning of the file as is the current convention) and places all non-cronR content at the top of the crontab. This prevents MAILTO from being placed beneath the cronR jobs as MAILTO must come before the cron job.
• Limitation of this implementation is that all cronR jobs must use the same MAILTO email address unless the user chooses to manually edit the file. If they do that, the next time cron_rm() is called, all the MAILTO values will be moved to the top of the file and then the last MAILTO would superceed all prior values ; once again the user would need to manually edit the file.
• This approach was adapted from the article Automating R Scripts with Cron.

Other Changes

Bug Fix

• This implementation also fixes a bug I encountered when I made repeated calls to cron_add() and cron_rm() in a crontab containing both cronR jobs and non-cronR jobs (or a MAILTO line). Each time there is a round-trip between cron_add() and cron_rm() a line sperating the cronR jobs and the non-cronR content is lost. This eventially causes a problem when all of the lines seperating the cronR and non-cronR content is removed as cron_rm() will throw the error "new crontab file is missing newline before EOF, can't install."

Warning Message

• Added Encoding: UTF-8 to DESCRIPTION to address the warning generated by roxygen when running roxygenise().

[jwijffels]

Thanks for the changes and the detailed description. Here some remarks:

• can you replace calls of paste0 with paste, I prefer to not increase R version dependencies for this change
• can you add a type argument to cron_rscript which uses the current behaviour as default and your code as another type option to cron_rscript, that will be the least invasive

[adamcagle]

No problem! I made those changes. Just let me know if there's anything else that's needed.

[jwijffels]

Thanks for the changes. Can you replace argument output_on_error = FALSE to type = c("default", "output_on_error") and user type = match.arg(type) inside the function and use argument type to do the logic, that will still allow to add other types in the future while making the function call the same. Like type = 'multiple' where you can pass multiple R scripts e.g. You can also bump the version and add a news item, I'll merge then.

[adamcagle]

Will do! That actually gives me another idea. You might want some scripts to generate an output everytime they run so that you'd get an email regardless of whether or not there was an error. I'll add output_always as a third option if you're on board with that.

[jwijffels]

I'm fine with other options regarding type. Feel free to add pull requests. Would be good to have some unit tests of this of course.

I didn't check in detail the change you did here: https://github.com/bnosac/cronR/pull/52/files#diff-e9a0c9c4bebffe527085d3173fc97dc8c1ae0d27d0fd699a59583525f6926c27R23 but I presume that will be fine.

[adamcagle]

Thanks for merging! I'll work on some unit tests next.