Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase the granularity of the "keep within" snapshot retention policy #2090

Merged
merged 3 commits into from
Jan 6, 2019

Conversation

plumbeo
Copy link
Contributor

@plumbeo plumbeo commented Nov 16, 2018

What is the purpose of this change? What does it change?

Increase the minimum granularity of the time ranges accepted by the restic forget --keep-within command from a daily granularity to an hourly granularity.

Was the change discussed in an issue or in the forum before?

Yes, in issue #2089.

Checklist

  • I have read the Contribution Guidelines
  • I have added tests for all changes in this PR
  • I have added documentation for the changes (in the manual)
  • There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
  • I have run gofmt on the code in all commits
  • All commit messages are formatted in the same style as the other commits in the repo
  • I'm done, this Pull Request is ready for review

@plumbeo
Copy link
Contributor Author

plumbeo commented Nov 16, 2018

I didn't add new tests covering the change to snapshot_policy_test.go yet because I'm not sure about how to generate the testdata.

@codecov-io
Copy link

codecov-io commented Nov 16, 2018

Codecov Report

Merging #2090 into master will decrease coverage by 4.13%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2090      +/-   ##
==========================================
- Coverage   50.78%   46.65%   -4.14%     
==========================================
  Files         176      176              
  Lines       14165    14169       +4     
==========================================
- Hits         7194     6610     -584     
- Misses       5920     6565     +645     
+ Partials     1051      994      -57
Impacted Files Coverage Δ
internal/restic/duration.go 76.47% <100%> (+1.47%) ⬆️
cmd/restic/cmd_forget.go 42.85% <100%> (ø) ⬆️
internal/restic/snapshot_policy.go 74.33% <100%> (ø) ⬆️
internal/backend/b2/b2.go 0% <0%> (-80.69%) ⬇️
internal/backend/swift/swift.go 0% <0%> (-78.45%) ⬇️
internal/backend/gs/gs.go 0% <0%> (-73.61%) ⬇️
internal/backend/azure/azure.go 0% <0%> (-69.46%) ⬇️
internal/backend/swift/config.go 36.95% <0%> (-54.35%) ⬇️
internal/checker/checker.go 64.54% <0%> (-3.87%) ⬇️
internal/backend/rclone/backend.go 66.08% <0%> (+1.75%) ⬆️
... and 2 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2434ab2...3edc723. Read the comment docs.

@plumbeo plumbeo force-pushed the within-hours branch 2 times, most recently from 7861138 to ecedbf3 Compare November 17, 2018 14:20
@fd0
Copy link
Member

fd0 commented Nov 24, 2018

Nice idea, I like it! Add the tests to snapshot_policy_test.go, then run the tests with go test -v -update -run TestApplyPolicy, then inspect the new (updated) files in testdata/. If they look good (the results are correct), commit the files. This technique uses so-called "golden" files to compare the result of an operation with the expected result without manually having to write the long and complicated files.

Copy link
Member

@fd0 fd0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add the tests, then I think this change is good to be merged. Thanks!

Make restic forget --keep-within accept time ranges measured in hours and choose
accordingly which snapshots to keep and which to forget. Add relative tests.
@plumbeo
Copy link
Contributor Author

plumbeo commented Nov 26, 2018

@fd0 I just pushed a modified commit that also add tests. Also, in the option description wasn't "older" supposed to be "newer"?

@fd0
Copy link
Member

fd0 commented Jan 6, 2019

Also, in the option description wasn't "older" supposed to be "newer"?

Huh, I think you're right!

Copy link
Member

@fd0 fd0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants