Retention policy when deleting packages

[peters]

MyGet supports retention policies. Our in-house projects publishes nupkgs for all PRs so that they may easily be tested using feature flags. All projects has been migrated away from MyGet after GitHub packages was GM-ed. Because there is no option for specifying retention policies using GitHub actions this means that after a PR has been merged the NuGet package still remains. If you have large packages, this wastes storage space. Ideally the package would automatically deleted when the PR has been merged but this will require us to integrate with libgi2sharp. This should not be that difficult but it consider it a nice-to-have feature.

GitHub Actions supports scheduling using a cron expression. This means that if we implement support for a simple retention policy gpr could be used to enforce one or multiple retention policies. We should not invest too much time into this feature as it very likely GitHub will implement this feature in the nearest feature as enterprise customers will not migrate due to the cost factor

• Retain the latest 5 prerelease packages (nupkg and snupkg). gpr delete -r ${{ github.repository }} --match -prerelease -k ${{ github.token }} --retain-policy 5
• Retain the latest 5 non-prerelease (stable) packages (nupkg and snupkg). gpr delete -r ${{ github.repository }} -k ${{ github.token }} --retain-policy 5

The default package name is ${{ github.repository }}.

[jcansdale]

@peters,

I'd like to include a policy for only deleting packages with 0 downloads or some maximum number of downloads. I'm wondering what the switch should be.

gpr delete ${{ github.repository }} --downloads 0
gpr delete ${{ github.repository }} --max-downloads 0
gpr delete ${{ github.repository }} --no-downloads

I'd want to pair it with the retain policy. For example, this might delete package versions with 0 downloads unless they are in the 5 most recent:

gpr delete ${{ github.repository }} --retain-policy 5 --max-downloads 0

Does that make sense? What would your preference be for the switch name?

[jcansdale]

Do you think this feature should have built in knowledge of SemVer or should we do more generic version string matching?

For example, we could support including or excluding a version string match:

# keep the 5 most recent pre-release versions
gpr delete ${{ github.repository }} --include -prerelease --retain-policy 5

# keep the 5 most recent non-pre-release versions
gpr delete ${{ github.repository }} --exclude -prerelease --retain-policy 5

[peters]

@peters,

I'd like to include a policy for only deleting packages with 0 downloads or some maximum number of downloads. I'm wondering what the switch should be.

gpr delete ${{ github.repository }} --downloads 0
gpr delete ${{ github.repository }} --max-downloads 0
gpr delete ${{ github.repository }} --no-downloads

I'd want to pair it with the retain policy. For example, this might delete package versions with 0 downloads unless they are in the 5 most recent:

gpr delete ${{ github.repository }} --retain-policy 5 --max-downloads 0

Does that make sense? What would your preference be for the switch name?

I like your suggestions but IMHO --include should be renamed to --match or --filter because of the --exclude option. Also I'd imagine it would be easier to understand --min-downloads 1, --max-downloads 0

[peters]

You could also introduce explicit switches such as --prerelease, --stable and then --match translates to "$PackageName.StartsWith". If you reference <PackageReference Include="NuGet.Versioning" Version="5.6.0" /> you can use NuGetVersion.Parse and check the NuGetVersion.IsPrerelease property :)

[peters]

Bonus feature: Show preview of packages that will be deleted and a confirmation prompt (Are you sure you want to continue?). For automation purposes this prompt must be bypassed if --accept-prompts is set. This can be easily achieved using https://github.com/khalidabuhakmeh/ConsoleTables

[peters]

In order to prevent regressions when adding new features it would be awesome if each command have corresponding integration tests. This is trivial because we can mock IRestClient.

[jcansdale]

@peters,

Show preview of packages that will be deleted and a confirmation prompt (Are you sure you want to continue?). For automation purposes this prompt must be bypassed if --accept-prompts is set.

I've got something similar to this in place (to avoid the prospect of deleting all packages in an organization 😉). By default, it only lists packages that would be deleted. You need to --force to actually delete them. 🙂

In order to prevent regressions when adding new features it would be awesome if each command have corresponding integration tests. This is trivial because we can mock IRestClient.

I think this filter will need some unit tests at the very least. I'd be a little scared of mocking GraphQL, but it might work. 😉

Feel free to jump on this one if you have the inclination!