feat: bugfix to snapshot pruning and allow snapshot config to accept positive integer for retention lifespan in days (resolves #10626, #10782, #6845, #3182, #10532)#12856
Open
ariane-emory wants to merge 25 commits intoanomalyco:devfrom
Conversation
- Changed schema to use .nonnegative() instead of .positive() - Updated cleanup() and track() to treat 0 the same as false - 0 and false both disable snapshots - Positive integers enable snapshots with N-day retention
Replace git gc --prune with direct directory management for snapshot cleanup based on configurable retention period. Snapshots older than the configured number of days are now deleted directly from the filesystem.
Changed snapshot configuration tests to verify the actual retention period calculation logic instead of only checking truthiness. Removed redundant test that looped through multiple integer values.
Added proper type annotations to resolve TS2367 errors in the retention calculation tests.
Contributor
|
The following comment was made by an LLM, it may be inaccurate: Based on my search results, I found one potentially related PR: Related PR:
These are related to snapshot management but appear to be addressing different aspects (file filtering and CLI commands respectively) rather than being direct duplicates of the pruning bug fix and retention configuration feature in PR #12856. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR corrects a bug in the current snapshot pruning implementation where old snapshots' directories are not being properly pruned: currently only individual objects inside the snapshot are pruned after their exceeds the retention time limit, not the folders in their entirety. This PR ensures that expired snapshots' folders are correctly pruned.
Additionally, this PR allows for the value of the
snapshotsetting inopencode.jsonto be either a boolean value (as is the case currently) or a positive integer controlling how many days snapshots should be retained for. A value of 0 is treated equivelantly to"snapshot": false, disabling the snapshots feature entirely.This feature will allow users to better control how much space is ultimately used by OpenCode for the storage of snapshots.
Tests are included to make sure that valid configuration values for
snapshotare parsed correctly.Resolves #10626.
Resolves #10782.
Resolves #6845.
Resolves #3182.
Resolves #10532.
This feature should also provide a means to mitigate numerous other issues involving complaints about a huge snapshot folder consuming excessive disk space.
Note: Pull request re-created after the original PR (#10628) was accidentally clobbered by a bad merge from upstream/dev.
How did you verify your code works?
Manual testing plus
bun testandbun typecheck: no new failing tests introduced relative to the current HEAD of dev. Dogfooding: I have been using this in my own fork since the original PR's (#10628) time of submission and it does appear to be working exactly as it was designed to. Yay!