CRON persistence

[maddsua]

Hello,

it doesn't look like there is an answer for this in the documentation.

Basically as of now it doesn't seem like gickup is tracking the last time it ran. As the result of that if a run was skipped for whatever reason (such as host being offline) it won't run again until the next scheduled date.

Since I am planning to have the service on my Intel NUC that doubles as my media center, there's a chance it won't be online for long enough to reliably be there when CRON triggers.

I think it could be a really useful feature to keep track of the last backup time so that we could trigger immediately on service start if the time interval since last run is longer than the set CRON period.

[cooperspencer]

Hi,
you could also add a normal cronjob instead of using gickups cron feature. Like @reboot, then it would run the backup every time you power up your media center.

[maddsua]

Hi,

I can't say I don't see this approach as feasible but it feels a bit wrong to offload scheduling to the system, especially when running gickup in a container.

Also, is there a way to somehow skip downloading the same repos over and over again when there are no changes in between the runs?

Both of these are more like nice-to-have's rather than serious concerns from the project's perspective. Yet it makes me consider writing my own backup-thingy, which would definitely end up being a horrible waste of time.

[cooperspencer]

I get where you are coming from. Ok, I'll look into it. Shouldn't be too difficult tbh.
to save bandwidth/data volume:
check latest commit on source -> check latest commit on destination -> if different, do backup

immediate backup:
have a file somewhere that has the latest backup date -> if older than the last cronjob, do backup (maybe make it configurable)

I could also try to add all the before mentioned information into a sqlite db.

[maddsua]

That is pretty much what I had in mind.

Speaking of activity, I don't think there is a good way to check each of the branches for updates. Because of that I wanted to look into the APIs provided by the sources themselves (GitHub, Lab, etc.). Usually they return a date when a repo was last updated. Not sure how reliable that is though.

I guess sqlite is unavoidable here, even though you can get away with writing timestamps to a file next to zips when using a local or an s3-like destination, that of course ain't gonna scale for all of the other options.

With CRON, yeah, this one is the easiest. Simply write current date to a file on each backup run. Then on the next startup check the duration since that date and if it's bigger than planned - run backup immediately.

Could probably do it myself if I manage to get enough free time this/next week. In any case that would definitely be a better idea than reinventing a wheel. The last thing FOSS needs is one more "competing" project out there.

[hammerbacher-com]

There is also anacron