autoupdate borg-cron-helper scripts

shankari commented 5 years ago

I'd like to automate my setup so that I don't have to fiddle around with manual updates. With your current release strategy, it seems like the easiest option to update is to pull from master periodically (maybe weekly?).

So my questions are:

is this a reasonable option? can I assume that most development work happens on a branch and master is typically stable?
does it make sense to add the git pull to the configuration scripts? I personally don't like this option because it is insufficiently modular and adds a network dependency for the backup script.
would you accept a PR for new system scripts for the git pull? I would only contribute scripts for systemctl since that is what I'm using.

rugk commented 5 years ago

can I assume that most development work happens on a branch and master is typically stable?

I can't promise it definitively, but this is the goal (and currently the case), so yes. The releases here are, however, (theoretically :wink:) better tested.

does it make sense to add the git pull to the configuration scripts? I personally don't like this option because it is insufficiently modular and adds a network dependency for the backup script.

Well… you are the sysadmin, so this is totally your decision.

Personally, I would rather use a different script, possibly even with a different user/permissions, as the user, who does the backup may not have all permissions to write to these files. (okay, usually it may be root)

would you accept a PR for new system scripts for the git pull? I would only contribute scripts for systemctl since that is what I'm using.

As I indicated, I do not really want to endorse a way to self-update my scripts, or I'd prefer using the latest tagged git state…

Generally I don't think it really needs to be included in the repo here, as it may be an really easy task and done for many apps. However, it may be useful, if you do verify my git signing key when downloading the update, so that sysadmins do use this security feature.

However, yet again that is already done/implemented for/in the unit tests actually, so you can also nearly re-use this. Everything else is just a git pull and a simple (systemd) trigger.

So I doubt it is really useful to add this as a separate script, but possibly the doc can be adjusted. Or the verify script can be generalized and moved out of the unit tests to make it accessible to all users of these scripts?

shankari commented 5 years ago

As I indicated, I do not really want to endorse a way to self-update my scripts, or I'd prefer using the latest tagged git state…

I'm happy to use the latest tagged git state, which I agree makes more sense anyway. However, git, unlike docker, doesn't have a built-in 'latest' tag that I can pull from. I'd have to figure out the latest tag version by doing something like this https://stackoverflow.com/questions/4277773/how-to-get-latest-tag-name

done for many apps

well, most apps publish to package managers (e.g. apt, npm, etc), so I don't think many projects need direct updating to the latest version from git. However, it is true that github is pretty popular so maybe somebody has already done this - I'll check.

At this point, I don't have time to do anything more sophisticated than setting up a timer that does git pull - I still have a bunch of setup to finish and photos to migrate before the end of the week - so I will just hack something up locally for now.

Thanks! and feel free to close the issue since I can't commit to when I can return to it.

rugk commented 5 years ago

package managers (e.g. apt, npm, etc)

There is no such thing for shell scripts, and this tool here is really too unpopular to be added to distros or so… (IMHO)

I may think about it. Personally I did not even thought of auto-updates, and rather considered people do it manually for this here. But yeah… I see why it is useful :smile:

shankari commented 5 years ago

There is no such thing for shell scripts,

True that there is no npm equivalent for shell scripts, but distro package managers do include collections of shell scripts (e.g. https://github.com/rear/rear/, https://launchpad.net/ubuntu/+source/rear)

If you did try to get it added to debian/ubuntu, I would upvote that proposal :) That would also make the install much easier because you could automatically add the timer scripts, start them, etc instead of sysadmins adding them.

Although, ideally, this would really be part of the borgbackup package install. Maybe they would pull data from two sources to build the package? Then if I apt install borgbackup, I will get both the binary (from https://github.com/borgbackup/), and the sample scripts (from https://github.com/rugk/borg-cron-helper) to start auto backups. Because there is no point in having a backup solution that doesn't take periodic backups.

certbot does something similar - it automatically adds the .service and .timer to renew the certificate from let's encrypt.

Just some thoughts if you want to take this further. Thanks for all the work you have done so far, and good luck!

rugk commented 5 years ago

If you want to package this here for any distro, feel free to do so… (I am not involved in Debian/Ubuntu packagers) Until now, I thought, it was not really popular/useful enough, as it "still" only consists of some wrapper scripts around borgbackup, basically…

dsteinkopf commented 5 years ago

Note from me as "user": I am happy the way it is. From time to time a check the commit log and manually do a git pull.

BTW. Thank you for these helper scripts!

rugk commented 5 years ago

Yeah, you could e.g. also use this new GitHub feature:

rugk / borg-cron-helper

autoupdate borg-cron-helper scripts #53