Feature/repo refresh option

[mirisbowring]

Hi,

coming from #247 (comment)

I implemented an environmental variable that enables / disables (by default) an AUTO_REFRESH option.
If this option is enabled, each ssh forced commands get appended a script to call the warehouse api to fetch the latest details about the repo.

This approach is better than any cronjob since it get's executed only if a borg activity has happened (not just on a timely basis).

I hope this get pulled since i expect this to be a useful feature for others also.

[mirisbowring]

@Ravinou what do you think about this? :)

[Ravinou]

Thank you for this contribution, which I am studying. Could you start by squashing your commits please and add the conventional scopes ?
It'll make it easier for me to read 😊. By the way, you can rebase your branch on main, I added husky to help with that recently 👍

Next, I'll have to take the time to study and test this, as you're touching on core functions, notably the repository creation shells and their regexes.

I still have my doubts about reintegrating the triggering of a task like this into borgwarehouse. Originally, v1 had a built-in cron. But it was removed because it was causing problems and nobody recommends doing that. This job should be given to another service. I'll study your PR, I promise, but I don't know if I'll approve it yet. Thanks in any case.

[mirisbowring]

I will rebase :)

Wouldn't it be easier to squash the commits here on the PR and i format the PR Text according to the conventional scopes? Then the newly created (squashed) commit by GitHub will be as you wish?

Or do you want to fast forward merge to preserve original signatures?

[Ravinou]

You can do only one commit "feat:", I will study it by merging it in a specific branch. Thanks.

[mirisbowring]

Hi,
I rebased and squashed the changes.
This change is still a bit different from v1 because it is not using any cron. it is just an additional ssh-forced-command that will be executed as soon as the borg command finishes (independend of success or failure since it does not iterfere in this case).

[Ravinou]

Thanks, it's much clearer. I'm currently working on token API integration. As soon as it's finished, I'll start working on your proposal in the next few weeks. Thank you for your patience.

[mirisbowring]

Hi @Ravinou I saw your latest relase. Before i invest time into solving the conflicts - are there chances that this PR get's merged?

[Ravinou]

Hi, for the moment don't do the rebase, I'll have a look when I get the time back ;)

[matthijskooijman]

This approach is better than any cronjob since it get's executed only if a borg activity has happened (not just on a timely basis).

I think there is an important downside of this: If no borg activity happens (i.e. all backups failing), then you will also not get any notification about this, AFAICS. Notifications about failing backups will rely on some other backup still (trying to) backup.