Do you really need a personal access token?

[sihil]

This looks really useful although I'm very reluctant to create a PAT.

Have you experimented to see whether this can be replaced with a packages: write permission? i.e.

name: Delete old container images

on:
  schedule:
    - cron: '0 0 * * *'  # every day at midnight

permissions:
  packages: write

jobs:
  clean-ghcr:
    name: Delete old unused container images
    runs-on: ubuntu-latest
    steps:
      - name: Delete 'dev' containers older than a week
        uses: snok/container-retention-policy@v1
        with:
          image-names: python-dev, js-dev
          cut-off: A week ago UTC
          account-type: org
          org-name: my-org
          keep-at-least: 1
          untagged-only: true

This certainly lets you push and pull containers but I don't know if delete is included in write. I wondered if you knew one way or the other.

[sondrelg]

Things change all the time, but last time I checked a PAT was required. Definitely understand your hesitation though - not entirely comfortable with it either.

[sihil]

Thanks for the quick reply. I will experiment and feedback just in case it has changed.

[sondrelg]

Please do 🥇 And I guess we can leave this open for a while in case anyone else has relevant input 👍

[sihil]

It hasn't changed. A personal access token is still required 😢

Would be great to understand if packages/delete will make it to the GITHUB_TOKEN permissions anytime soon @NamrataJha et al.

[andygrunwald]

I can confirm that, at the moment, an own personal access token with packages: delete permission is required.

GITHUB_TOKEN is not enough at the current moment.

[tuler]

This GitHub blog post states GITHUB_TOKEN is supported in delete operations

[sondrelg]

I just tried switching in one of my workflows, and it resulted in a 500 internal server error 🤔

[timofey-drozhzhin]

This GitHub blog post states GITHUB_TOKEN is supported in delete operations

The article is referring to a different type of API endpoint used by docker CLI to login, push, pull, rm images... that type of API is in fact supported by ${{ secrets.GITHUB_TOKEN }} and is used by Docker Login Action. However, afaik, docker cannot remove container images from private repositories.

To delete private container images, you need access via api.github.com REST API endpoint, which as of now is not supported by ${{ secrets.GITHUB_TOKEN }}.

[ruffsl]

It hasn't changed. A personal access token is still required 😢

I've opened a community discussion on this topic over here:

• Retention Policy support for GHCR hosted images community/community#50123

Feel free to comment on or upvote the discussion to boost it's visibility/priority.

[ad-m-ss]

Did anyone test fine-grained tokens https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/ for that?

[rob-whittle]

Not sure if something has changed with the API, but the github provided action for cleaning up packages does work with the standard runner token. As does this action.

Unfortunately neither provide the option for excluding an image from deletion by tag 😞 .

[0x2b3bfa0]

The other actions query the packages individually, and that operation works with the default token, as long as the repository can manage its own packages:

• https://api.github.com/orgs/{organization}/packages?package_type=container 🚫
• https://api.github.com/orgs/{organization}/packages/container/{name}/versions ✅

This action doesn't have an easy migration path to the latter, because it also supports regular expressions for package names.

[mering]

@0x2b3bfa0 this is also my observation. In case we can identify the special case of only completely specified package names, it should be possible to use without a PAT similar to what I did in Chizkiyahu/delete-untagged-ghcr-action@3202d05.