resticprofile icon indicating copy to clipboard operation
resticprofile copied to clipboard

New schedule section for configuration v2

Open creativeprojects opened this issue 3 years ago • 4 comments

This PR is adding support for the schedules section on the configuration format v2:

schedules:
    full-backup: # give a name to your schedule
        group: full
        schedule:
            - "Mon..Fri *:00,15,30,45" # every 15 minutes on weekdays
        permission: user
        run: backup # backup is the default if not specified

    other:
        profiles:
            - root
            - mysql
        schedule:
            - "Sat,Sun 0,12:00" # twice a day on week-ends
        permission: user
        run: prune
  • [ ] Implementation
  • [ ] Tests
  • [ ] Documentation
  • [ ] Ready for review

creativeprojects avatar Oct 27 '22 22:10 creativeprojects

Codecov Report

Patch coverage: 51.48% and project coverage change: -0.12% :warning:

Comparison is base (b00c8a0) 77.20% compared to head (12e29b0) 77.09%. Report is 3 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #146      +/-   ##
==========================================
- Coverage   77.20%   77.09%   -0.12%     
==========================================
  Files          92       93       +1     
  Lines        9949    10020      +71     
==========================================
+ Hits         7681     7724      +43     
- Misses       2003     2032      +29     
+ Partials      265      264       -1     
Flag Coverage Δ
unittests 77.09% <51.48%> (-0.12%) :arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed Coverage Δ
config/schedule_config.go 75.61% <0.00%> (+15.99%) :arrow_up:
schedule/handler_crond.go 12.73% <0.00%> (ø)
config/info.go 93.06% <14.29%> (-1.30%) :arrow_down:
schedule/handler_systemd.go 19.25% <16.67%> (ø)
schtasks/taskscheduler.go 47.80% <16.67%> (ø)
config/schedule.go 28.21% <28.21%> (ø)
schedule_jobs.go 30.36% <33.33%> (ø)
commands.go 53.72% <50.00%> (+0.04%) :arrow_up:
schedule/handler_darwin.go 49.58% <50.00%> (ø)
schedule/handler_windows.go 26.67% <50.00%> (ø)
... and 6 more

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

codecov[bot] avatar Oct 27 '22 22:10 codecov[bot]

I finally got a bit of time to do some work on the new scheduling configuration.

@jkellerer I wanted to discuss a few options before I go further. The way we call resticprofile from the scheduler will have to change. That's because we allow a list of profiles to be part of the schedule (which I think is a good thing anyway).

From now I can see two options:

  • add a --profiles profile1,profile2 option. This is the closest to the current implementation. We can change the name of the schedule and it's still going to work. The schedule configuration is transformed into command line flags. If we change the list of profile we have to unschedule and schedule again.
  • add a --run-schedule name option. With this option we don't need to transform the configuration into flags. We just need to read the schedule section when we start the job. This is a bit different than what we do now but it would make it much easier to change the configuration without rescheduling the jobs. One drawback though is that we cannot change the name of the schedule.

By writing it I realise I like the second option a bit more, but I wanted to have your opinion on it 😉

creativeprojects avatar May 06 '23 13:05 creativeprojects

Reading it, intuitively, I also like option 2 more (before reading the last line 😀). So looks like we're on the same page.

jkellerer avatar May 06 '23 13:05 jkellerer

Regarding the name.. I was thinking that it might be something to consider to have kind of cache and/or state storage which might be used for all sorts of things including detecting name changes.

While it may not help now, we could use it later to automatically act when name changes are detected (not only in this case). So it may not necessarily be a disadvantage.

jkellerer avatar May 06 '23 13:05 jkellerer

Replaced by #333

creativeprojects avatar Mar 04 '24 20:03 creativeprojects