3

I have a GitHub worflow which builds and deploys a snapshot version of a library as a GitHub package, e.g., mycompany.mytool.1.0.0-SNAPSHOT.jar. Whenever I make a new build and deploy, a new asset is created, like, e.g., mycompany.mytool.1.0.0-20210723.145233-1.jar instead which is then somehow associated with the SNAPSHOT tag. This all seems to work and I can access mycompany.mytool.1.0.0-SNAPSHOT.jar without problem.

My question now is, how can I get rid of all these older versions of this jar? Actually I just want to keep the latest version. I can delete them manually via the web-interface but that is a more than awkward task. I would somehow like to automate this too.

mipa
  • 10,369
  • 2
  • 16
  • 35
  • Curious how you were able to delete assets from the SNAPSHOT version? I'm not able to find a UI to do that, only delete the entire *version*. – E-Riz May 03 '23 at 20:23

1 Answers1

2

This is not possible as of this writing. GitHub staff member Jamie Cansdale wrote this in their community forum:

SNAPSHOT versions are exposed as artifacts inside a regular versions. There isn’t an API for cleaning up artifacts, only whole versions.

(source)

Which means that a single SNAPSHOT version (like 1.0.0-SNAPSHOT) will accumulate all builds you make, and all artifacts will show up on the Assets list to the right of the web page.

The only practical solution I can think of, is that you delete the whole version from a script, before publishing each build's artifacts. Then you'd have the effect of having a single set of artifacts stored as part of the 1.0.0-SNAPSHOT version name.

However this solution is not ideal: public package versions cannot be deleted if they are popular enough (probably to avoid squatting attacks):

If the package is public and the package version has more than 5,000 downloads, you cannot delete the package version. In this scenario, contact GitHub support for further assistance.

j1elo
  • 1,029
  • 8
  • 21
  • Thank you for this clarification. The restriction you mention is not relevant for me because the packages in question are private anyway and not public. – mipa Dec 17 '21 at 13:07
  • Almost 18 months later, is there still no way to have GitHub Packages not keep old builds as assets? Seeing as GitHub charges based on the amount of storage used, this seems like a pretty bad limitation. – E-Riz May 03 '23 at 19:42