Feature Request: Delete unused packages

[riker09]

When browsing the package registry on GitHub Packages I can see an indicator on how often a certain package version has been downloaded. I have several packages that have never been downloaded. They have been built before I fully setup a CI pipeline.

I don't know if this is a nice feature to have, but maybe you could implement a "delete packages that have been downloaded fewer than X times" feature? Defaults to zero. Maybe in conjunction with the "older than X days" feature? Would look like this: "Delete packages that are older than X days and have been downloaded Y times or less".

[Gakk]

I don't know if this is a nice feature to have (...) [riker09]

I can confirm that this indeed is a very nice feature to have – especially in combination with other settings 🙂

We have a lot of repositories, packages and versions, and we would like to clean up old pre-release packages that has not bee used by anyone in the last X days.

When using dependabot sometimes there are a lot of updates, and for every PR opened we build a pre-release package. After merging in the PR we also create a pre-release package.

Currently we keep the last 10 pre-release packages, but often this is not enough, as someone might reference some older pre-release packages when implementing a feature.

We would really like to be able to delete all pre-release packages that are older than 30 days and has not been downloaded in the last 30 days – and still keep the last 5 pre-release packages 😇

[vincentbriglia]

Since Organizations pay for Storage for Actions and Packages, it's imperative that we have a finegrained way of deleting organization packages that are:
a) private and internal
b) not in use (ie: 0 downloads)

for the same reasons mentioned above: to remove pre-release, alpha, intermediate, preview and other types of packages that use up space.

Sadly the GitHub API doesn't seem to provide the information about no of downloads, even though it's available in the UI.

[JoshMcCullough]

Suggestion: stale-days: <days> where <days> is the number of days before now that the package has had 0 downloads. E.g. "delete package X if it hasn't been downloaded in 7 days". And it should respect the other settings such as min-versions-to-keep, etc.

The goal here would be to not delete a package if it is still being downloaded e.g. I'd configure it as:

package-type: npm
package-name: my-package
min-versions-to-keep: 5
stale-days: 30

And therefore, a version of my-package will be deleted if is not one of the newest 5 versions, and it has not been downloaded within the last 30 days.

---

I realize this request is not as simple as it sounds, since the API may need to be updated to support the "# of downloads within X days" question.

[rmunn]

Sadly the GitHub API doesn't seem to provide the information about no of downloads, even though it's available in the UI.

Currently the only way to get that info appears to be to get the html_url from the GitHub API, fetch the HTML page, and scrape it for the div that contains the download activity, which will look something like this:

<div class="mb-5 mt-n1">
  <h4 style="margin-bottom: 10px;">Download activity</h4>
  <ul class="list-style-none">
    <li class="d-flex mb-1">
      <span class="text-left color-fg-muted">Total downloads</span>
      <span class="flex-auto text-right text-bold">0</span>
    </li>
    <li class="d-flex mb-1">
      <span class="text-left color-fg-muted">Last 30 days</span>
      <span class="flex-auto text-right text-bold">0</span>
    </li>
    <li class="d-flex mb-1">
      <span class="text-left color-fg-muted">Last week</span>
      <span class="flex-auto text-right text-bold">0</span>
    </li>
    <li class="d-flex mb-1">
      <span class="text-left color-fg-muted">Today</span>
      <span class="flex-auto text-right text-bold">0</span>
    </li>
  </ul>
</div>

That's not reliable (you'd have to put Accept-Language: en-US into the HTTP query and it would still break every time GitHub updates their UI) and would be slow as it could only be done one package at a time. But it would be possible to put that kind of logic into a workflow of your own, even if it's not something that should go into the delete-package-versions action.