Add support for deletion of container and npm packages about delete-package-versions

[tinaheidinger]

@peter-at-work
Hello from GitHub Packages! We started to work on refactoring this Action so that it supports our package registries that run on the new architecture. You will see an updated version very soon.

[Yikun]

+1 for ghcr packge version deletion support!

[vinayakkulkarni]

Also, there should be a way to auto-delete the untagged docker images stored in the registry for that particular repo

[tinaheidinger]

This has been resolved with v4.0.0 of this Action.

Required steps to use this Action for the new GitHub Packages architecture:

• Update action’s version from v3 to v4
• Supply mandatory package-type and package-name params
• The repository running the workflow must have Admin permissions over the package

[csaba-kovacs]

@nishthaGupta Ah yes, i set the permission/package scope to write on the job level and it solved it. Thanks!:)

[csaba-kovacs]

Is there any progress here?

[csaba-kovacs]

@DaveFPM i got the same error, then i added the owner and token and it works

- uses: actions/delete-package-versions@v4
  with: 
    owner: 'github'
    package-name: 'test-package'
    package-type: 'container'
    token: ${{ secrets.GITHUB_PAT }}
    min-versions-to-keep: 3

[s-anupam]

@DaveFPM package-name will be dave-test. Also, if you are using GITHUB_TOKEN (default), please ensure that the repository is given admin access by going on package settings page -> manage actions access

---

i got the same error, then i added the owner and token and it works

@csaba-kovacs owner takes the default value of current repo owner and is required if you want to delete package in a different org than the one where workflow is executed. token takes the default value of GITHUB_TOKEN. If repository is not provided admin access to package as mentioned above, then you need to provide a PAT with package:read and package:delete scope. If admin access is given to the repo, then token is not needed

[peter-at-work]

This issue has caused our organization npm package registry to grow too large (started August/September), accumulating so many non-stable versions, because our retention policy is not being processed, via this GitHub action.

I understand the code for this GitHub action and would like to help implement a fix. But what exactly is it in the new registry architecture that's causing an issue with this action?

Described here in the docs https://docs.github.com/en/packages/learn-github-packages/deleting-and-restoring-a-package#deleting-a-version-of-a-repository-scoped-package-with-graphql is that a GraphQL mutation cannot be used to delete the package anymore. Is that the only problem, and we could perhaps modify the delete-version.ts code to use the Packages REST API to delete?

Or is there more to the permissions thing? Trying to execute the GraphQL query for the list of versions in one of our npm packages, it seems to return a very short list -- versions that were published around August. Versions that were published after some date in August, though still appearing in the Web UI, are not returned in the GraphQL query. Is the GraphQL query operation also not supported with the new architecture (which would lead to a bigger fix for this GitHub action)?

[cpratap994]

@peter-at-work The GitHub Packages GraphQL API does not support containers or Docker images that use the package namespace https://ghcr.io/OWNER/PACKAGE-NAME, or npm images that use the package namespace https://npm.pkg.github.com/OWNER/PACKAGE-NAME. For more information about GraphQL support, see "Deleting a version of a repository-scoped package with GraphQL."

https://docs.github.com/en/packages/learn-github-packages/deleting-and-restoring-a-package#:~:text=The%20GitHub%20Packages,with%20GraphQL.%22

it means new npm packages published after August will not appear on GraphQL output.

[peter-at-work]

it means new npm packages published after August will not appear on GraphQL output.

I really want to start a discussion on this. Our organization really needs this GitHub action for running our artifact/package retention policies. We could readily fork this action repo and refactor within our fork, but we also would want to contribute back to the GitHub Actions community and provide a usable fix. There are a few roadmap topics we would want to get some clarification on.

In the public repositories for @actions, it seems that this is the only GitHub Action that deals with GitHub Packages. There aren't any actions for publishing into GitHub Packages because the individual tools are used (e.g., npm publish, nuget push, docker push). Because keeping the package store in a manageable size is a maintenance-type activity, it makes sense that this custom GitHub Action is used for this. Is GitHub committed to continue maintaining this repo (i.e., patches, dependency updates) even when we get it working? Or are there plans to just deprecate this action and have organizations write their own action?

It is documented that GraphQL doesn't support NPM and Container packages, but is it in the roadmap for GraphQL to support this? I don't see any technical reason preventing the implementation of proper GraphQL resolvers to handle the different architecture for NPM and Container packages. If that's the case, should we just wait for GitHub to develop the appropriate resolvers? The GraphQL resolvers are, understandably, private to GitHub, and we won't be able to contribute to it.

If GraphQL support is not ever planned, then is a refactor to the Packages REST API the right approach? With the Packages REST API, there is one additional requirement of providing the package_type (e.g., npm, container, etc.) and that means a breaking change and a major rev to the version of this GitHub action.

Also, will the different architecture for NPM and Container packages introduce some conditional code? The other package types are still associated with repos, so the repo parameter could still be useful. But the Packages REST API doesn't seem to use or require the repo parameter. NPM and Container packages look like they are associated with the owner/organization by default. Is the roadmap to move all the other package types to this new architecture and associated to the organization? It also means that GITHUB_TOKEN cannot be used for this action because it is limited in scope to the repo where the action is running against. It will now need a separate PAT with the appropriate permissions.

[dwivedine]

We are working on supporting this action for all the registries migrated to the new architecture. The tentative release date is 20th January 2023.

[peter-at-work]

This has been resolved with v4.0.0 of this Action.

Required steps to use this Action for the new GitHub Packages architecture:

• Update action’s version from v3 to v4
• Supply mandatory package-type and package-name params
• The repository running the workflow must have Admin permissions over the package

We just tested v4 of the action, and it properly purged old versions of our NPM packages and matched the retention policy we specified.

🙏Thank you!

[jcansdale]

Deleting untagged multi-arch images might be tricky because the individual arch images aren't tagged (AFAIK).

[Catzilla]

Deleting untagged multi-arch images might be tricky because the individual arch images aren't tagged (AFAIK).

Have an idea
Information about tagged arch images may be obtained directly from registry with request:
GET https://ghcr.io/v2/<username>/<packagename>/mainfests/<tag>
(Requires Authorization header with bearer token from GET https://<username>:<github_token>@ghcr.io/token)

[peter-at-work]

As an organization (and paying for GitHub Enterprise), we still a prefer a GitHub-authored/sanctioned action for processing our package retention policies. Some organizations have tight security restrictions on what open-source packages can be incorporated into their software development lifecycle. The reason is often dependent on the size, reputation, and longevity of the maintainers of the packages, to minimize the risk of rogue actors arising in the software supply chain.

The action implemented in https://github.com/SmartsquareGmbH/delete-old-packages has more recent activity and has technically surpassed the features of this action. It uses a strategy-based (GraphQL, REST) approach to this issue and have addressed this limitation on npm packages with their v0.6.0 release.

Can we get some thoughts from the maintainers on what the roadmap is for this GitHub-authored action?

[DaveFPM]

@tinaheidinger how do I make it work for GHCR packages? I tried a few different things but always get

Error: get versions API failed. Package not found.

This is my config:

      - uses: actions/delete-package-versions@v4
        with:
          package-name: 'davefpm/dave-test'
          package-type: 'container'
          min-versions-to-keep: 2

[csaba-kovacs]

@s-anupam even if i have the Manage Action access set to the repo with admin role still gives me API error without using token.

[nishthaGupta]

@csaba-kovacs Can we know whether the correct permissions are set for the GITHUB_TOKEN over packages as write? Please refer to this link to set up permissions https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

[DaveFPM]

@s-anupam Thanks for that, it worked. But does it also support ignore-versions? I'm trying to have it only delete beta/non beta packages depending, but it doesn't seem to work:

      - name: Docker cleanup develop images
        if: github.ref == 'refs/heads/develop'
        uses: actions/delete-package-versions@v4
        with:
          package-name: 'dave-test'
          package-type: 'container'
          min-versions-to-keep: 2
          ignore-versions: '^((?!beta).)*$'

      - name: Docker cleanup production images
        if: github.ref == 'refs/heads/main'
        uses: actions/delete-package-versions@v4
        with:
          package-name: 'dave-test'
          package-type: 'container'
          min-versions-to-keep: 3
          ignore-versions: 'beta'