switchtrue / frosty Goto Github PK

The time taken to zip the artifacts is not taken into account, therefore timings can look like:
Command Start Time: 01:00:00
Duration: 2.6m
Transfer Start Time: 01:07:59

Note the gap between the transfer start time and the command start time + duration.

There should be a zip time indicator in the report.

The errors are only reported in the email if the script exits with a non-zero exit code. It is possible for scripts to have errors but not properly terminate with an appropriate exit code leading to a mis-leading email report that the job completed successfully.

For example with the following script, if the frosty user does not have permissions on /svn/svndata the job complete successfully even though an error is thrown in the svnadmin line.

#!/bin/sh

for D in `find /svn/svndata/* -maxdepth 0 -type d`
do
  REPONAME=`basename ${D}`
  svnadmin hotcopy ${D} $FROSTY_JOB_ARTIFACTS_DIR/$REPONAME --clean-logs
done

Currently the bucket name is hard coded to "frosty.backups" AWS enforces that buckets have unique names across the entirety of S3. As such frosty is going to error if more than one person uses it.

It would be good if the bucket name could be configuration in the .frosty.config file and if not found here then is should fallback to a sensible default such as frosty.backups..

At the moment Frosty requires the configuration to create files in a particular location and only once they are written are they uploaded to S3. This means that if you have a 50Gb database you need 50Gb to store it locally before uploading. Supporting streams would remove this requirement.

Optionally allow the AWS URL to be overridden so that alternatives to S3 such as minio can be used.

S3 lifecycle policies support the ability to move an object to glacier after a certain amount of time. It would be good if Frosty could manage this via the frosty.config.

Note: This is still currently possible if you set up the bucket in S3 manually and then don't include any lifecycle config in the frosty.config file. With no lifecycle policy in the config Frosty just uses whatever is already pre-configured in AWS.

No error is reported if the script does not have execute permissions, simply the job is marked as failed with no explanation.

This probably raises issues around the reporting of other errors too and a thorough audit should be carried out.