Also, I donāt think the Graph API backends will work quite yet (unless you generate your own AuthID), as it looks like the Duplicati OAuth service hasnāt been updated to include the new protocols. The pull request has been accepted, it just looks like the new version hasnāt been deployed.
The problem is that the style.less is not ācompiledā to generate a new syles.css. I modified only the less-file and did not add the compiled styles.css to my commit.
Thought this is done automatically whenever a new release is created, sorry!
Does this functionality outright skip backup jobs? Because I think it would be better if the āon battery disableā acted somewhat more like having duplicati paused, in that when plugged back in, there would be a queue of (up to 1 of each i suppose) backup jobs ready to run.
The way itās implemented now, a scheduled backup is simply skipped (although clicking āRun nowā while on battery will still run the backup).
Having the skipped backups run upon plugging in would be really nice. I think there may be some subtleties that we would have to be mindful of. For example, suppose a backup is skipped while on battery and enqueued. While still on battery, the user then edits the settings for that backup. Which āversionā of the backup would users expect to be run upon plugging in?
Iām not 100% sure how this is handled now, but I would expect it to be handled about the same way that un-pausing duplicati handles it (if itās actually handled at all). And in general I would think if 2 instances of a job queue up against each other, the latest āversionā would take precedence and supersede the previous one.
Ok. I created an issue in GitHub to keep track of this feature request.
Yes, I have a lot of loose ends I need to tie up, but I will update the service as soon as I have time to monitor it afterwards.
I have not figure out what the best strategy for dealing with this is. It could be part of the build script, but then we end up having some latent issue that only shows up after a release. It would be nice if we could rebuild the .css file during normal builds, but I donāt like tinkering with the VS project files for that.
One possibility is to use a pre-commit (or pre-push, etc.) hook. Newer versions of Git allow you to specify the location of the hooks directory, which allows the hook scripts to be committed as part of the repository as well. We can then potentially reject the commit (or push) at some point if compiling the style file results in a dirty working tree.
