added a note for 'limit by size' deletion logic. #291
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Pull request overview
This PR adds documentation to clarify how the deletion order works when "Limit by size" is selected in retention rules. The new note explains that deletion is based on semantic versioning (lowest version first) rather than date pushed, and provides concrete examples to illustrate this behavior.
Key Changes
- Added a Note component to the "Deletion order" section explaining semantic version-based deletion for "Limit by size" setting
- Included examples showing how packages are prioritized for deletion based on version numbers
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <[email protected]>
ralph-mcteggart
left a comment
ralph-mcteggart
left a comment
There was a problem hiding this comment.
Sorry not your changes but I just thought since we're here. Approved anyway in case you just need to clarify confusion for someone. Would just be nice to get this sorted while we're at it.
|
|
||
| ## Other considerations | ||
|
|
||
| When multiple parameters of a retention rule are enabled (it's value is set higher than zero) and a package meets none or any of the conditions `(condition1 OR condition2 OR condition3)` for those parameters, the package will be kept. |
There was a problem hiding this comment.
Mind fixing this while you're here? its. I also actually wonder if this is even true? It's confusingly written but I understood it to be any condition
| This means that, in order for a package to be deleted, it needs to meet **all** of the conditions `(condition1 AND condition2 AND condition3)` in the retention rule, and not be excluded by the [`retention_count_limit`](#limiting-the-number-of-packages-to-delete) parameter when all packages to delete are [ordered](#deletion-order). | ||
|
|
||
| ### Limiting the number of packages to delete | ||
| The **Limit by count** option defines the number of packages to keep. For example, if we set its value to `4` and only a total of `3` packages meet the criteria, then `0` packages will be deleted. But if `5` packages meet the criteria, then `1` will be deleted and `4` will be keep in the repository. |
There was a problem hiding this comment.
More errors in this doc 🙈 will be kept
| | Limit by count | `retention_count_limit` | The maximum number of packages to retain. Set to zero to remove this criteria from the rules to apply. | | ||
| | Limit by size | `retention_size_limit` | The maximum total size (in bytes) of packages to retain. Set to zero to remove this criteria from the rules to apply. | | ||
| | Group packages by Name | `retention_group_by_name` | If checked, retention will apply to groups of packages by name rather than all packages. For example, when retaining by a limit of 1 and packages `PkgA 1.0`, `PkgB 1.0` and `PkgB 1.1` are uploaded; only `PkgB 1.0` is deleted because there are two (2) `PkgBs` and one (1) `PkgA`. | | ||
| | Group packages by Format | `retention_group_by_format` | If checked, retention will apply to packages by package formats rather than across all package formats. For example, when retaining by a limit of 1 and packages `PythonPkg 1.0` and `RubyPkg 1.0` are uploaded, no one is deleted because they are different formats. | |
There was a problem hiding this comment.
no packages are as opposed to no one is
Clarified deletion logic for packages when 'Limit by size' is selected, including examples.
colinmoynes
left a comment
colinmoynes
left a comment
There was a problem hiding this comment.
@ralph-mcteggart Does this make more sense?
Definitely clearer yep |
Added a new note to the deletion order section to notify of how deletion orders work for the 'limit by size' setting.