Cronjob wrapper script equivalency

[william-aaron-CFA]

Barring a few exception, all or our cronjobs are either invoking an individual script, or are invoking a wrapper script which runs a set of subscripts. This design should not be complicated by having a CronJob(Node) documented as a separate entity from a CodeFile(File) serving as a wrapper script.

The point is to simplify the intake of data. Any edge case nuance to this design can be recorded in the NodeMetaData table for the time being.

[william-aaron-CFA]

This will require reworking the attributes of the CronJob(Node) class to something like a CronJob(CodeFile) class, in which we use the CodeFile attributes to denote the behavior of the wrapper script.

[william-aaron-CFA]

The most common structure of a cronjob in our system is

• Changing a directory: cd ${SPACE_WEATHER}/ACE/Scripts
• Invoking an environment: ${ENV_FLIGHT}
• Calling the wrapper script: ${SPACE_WEATHER}/ACE/Scripts/ace.sh
  • Or calling an individual script with command line variables: python alert_ace.py -m flight
  • Keep these possibilities in one attribute
• Writing all output to a log file: ${HOME}/Logs/ace_main_new.cron 2>&1

Not all of these attributes are necessarily filled so allow nullability, except for the specific CodeFile being run by the cronjob, wrapper script, perl script, python script, ect.