feat(core): repository APIs to identify snapshots using latest~N

[nardoor]

No description provided.

[codecov]

Codecov Report

❌ Patch coverage is 85.71429% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 42.3%. Comparing base (59ad1df) to head (048d2af).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
crates/backend/src/rclone.rs	0.0%	2 Missing ⚠️
crates/core/src/commands/snapshots.rs	87.5%	1 Missing ⚠️
crates/core/tests/integration.rs	66.6%	1 Missing ⚠️

Additional details and impacted files

Files with missing lines	Coverage Δ
crates/core/src/commands/forget.rs	84.6% <ø> (ø)
crates/core/src/error.rs	67.1% <ø> (ø)
crates/core/src/repofile/configfile.rs	37.5% <ø> (ø)
crates/core/src/repository.rs	45.1% <100.0%> (+1.5%)	⬆️
crates/core/tests/integration/snapshots.rs	100.0% <100.0%> (ø)
crates/core/src/commands/snapshots.rs	80.0% <87.5%> (+55.0%)	⬆️
crates/core/tests/integration.rs	77.7% <66.6%> (-8.0%)	⬇️
crates/backend/src/rclone.rs	8.5% <0.0%> (-0.1%)	⬇️

... and 14 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[aawsome]

Hi @nardoor Is there something open from your side on this PR? IMO it should be only about some unit tests to increase test coverage..

[nardoor]

Hi @nardoor Is there something open from your side on this PR? IMO it should be only about some unit tests to increase test coverage..

Hello @aawsome ,

You are totally right, I just need to add some tests. I'll get it done asap.
Sorry for the delay

[nardoor]

@aawsome

I would love to have feedback on the tests I added, this is the first time I do integration tests for rustic.
I took inspiration from other integration tests.

I first tried to use InMemoryBackend for those tests but couldn't get it to work. So I took a more abstract approach.

Also I noticed that rustic_core has a dev-dependency on rustic_testing.
However I observed that we can't really use InMemoryBackend in rustic_core unit tests (I tried) because:

• rustic_testing also has a dependency on rustic_core
• and using InMemoryBackend WriteBackend methods in a rustic_core unit test resulted in a compilation error about Multiple definitions for WriteBackend (one in the rustic_core crate, another in the rustic_core dependency of rustic_testing (those are the same project (same filesystem path), but I believe the circular dependency just doesn't cut it)

[aawsome]

I would love to have feedback on the tests I added, this is the first time I do integration tests for rustic. I took inspiration from other integration tests.

The tests are OK from my POV. You could try to only once create a repo containing snapshots for all test cases and then run all tests (which do not modify the repo) on them, that would simplify the tests and speed them up a bit. But I am also fine with leaving them as-is.
I approved the change, if you want to leave the tests, you can merge this PR.

[aawsome]

LGTM! Thanks a lot @nardoor

[nardoor]

The tests are OK from my POV. You could try to only once create a repo containing snapshots for all test cases and then run all tests (which do not modify the repo) on them, that would simplify the tests and speed them up a bit. But I am also fine with leaving them as-is. I approved the change, if you want to leave the tests, you can merge this PR.

Thanks for the feedback, I added a commit to apply your suggestion, I used a LazyLock . Maybe you had another way to do it in mind. If so I'm curious about it.

Otherwise I think we are pretty good to merge!

[aawsome]

I used a LazyLock . Maybe you had another way to do it in mind. If so I'm curious about it.

I think using #[fixture] (like in set_up_repo()) with #[once] from rstest (see https://docs.rs/rstest/latest/rstest/attr.fixture.html) should also do it.

[nardoor]

I think using #[fixture] (like in set_up_repo()) with #[once] from rstest (see https://docs.rs/rstest/latest/rstest/attr.fixture.html) should also do it.

This makes total sense, I didn't know we could use once with rstest's fixtures.
I re-implemented the repo and snapshots setup :)

Note that:
I would have preferred that repo_and_snapshots returned a Result but I struggled to make it work.

• using once is kind of like using a LazyLock, we can only get a reading ref on it
• then I tried using Result::as_ref which works to get the inner result
• but I couldn't manage to use the try operator, because we also have a ref on an anyhow error (which I tried mapping to something else but eventually gave up as it's "only tests")

[aawsome]

LGTM