HTTP error 404 on deletion stops processing

[ehuelsmann]

Hi,

Thanks a lot for this Action! I've started using the action to clean up old packages in our org (ledgersmb); for the last - and most used and until now most often manually cleaned - package, I'm getting a 404 on the DELETE call. (See https://github.com/ledgersmb/ledgersmb-docker/actions/runs/12526197538/job/34938501087). Although it's obviously unexpected that the package doesn't exist, but I'd say this should be a WARNing, not an error, because the end result is the intended result: It doesn't exist.

Regards,
Erik.

[rohanmars]

Hi @ehuelsmann

That's great to hear.

Definately agree. I saw the same thing in one of my own repos a few weeks ago. I think it's a github API error/bug/timing issue. It doesn't make sense for the package API to return a package to which a delete then returns a 404. I've coded around it by catching 404 and printing out a warning (as you've also suggested). All other errors will trigger errors still. I've only done the work currently in my own fork. I'll merge/release sometime soon.

ee7b64f#diff-df3f033f405e2152d400f4bc608d95c38e2c37eac9e4ec3c3d951320abe56bab

[rohanmars]

In my case I actually saw a 500 error followed by a 404 in the logs. The retry layer retried the github API call from the 500, but the delete call went through even though it returned a 500. Your log doesn't have the same flow. More strange the package API actually returned that package but deleting it caused a 404, it could be a timing issue if the image was just built and then deleted. The fix I have will at least swallow those errors.

[ehuelsmann]

In my case, two workflows used the action, triggered some time apart (a minute?); both failed, which seems to contradict your reasoning. Maybe I should register a support issue with GitHub if the package keeps being reported even after a cleanup of your action has been successfully run on our repository. For now, I'll see what happens after several runs with your "continue on 404" change.

[rohanmars]

How are the images pushed into that repository/package? From the same repo or from a different repo pipeline? It may be a permission problem. The default GitHub token may not have permission to delete that package, even though it can see it and get the manifest.

It might be a useful test to use a PAT token with the cleanup action if it was pushed into the package using a PAT from a different repo.

[ehuelsmann]

The packages are pushed through different means, but to provide a bit more context: I've implemented container image cleanup for all packages listed at https://github.com/orgs/ledgersmb/packages ; the dev-* images are built and pushed from GitHub Actions using Docker Buildx, from the "development docker image". The ledgersmb_circleci-* images are built and pushed from GHA using Docker Buildx too, from the circleci images repo. These all clean up correctly - without the 404 error. (Which gave me confidence to move forward to running cleanup on the most important package repository: the one with the official releases).

Then the last package (container images), is built on my laptop during releases for LedgerSMB. The build uses Docker Buildx and is a multiarch build (which the dev-* and ledgersmb_circleci-* builds are not). The GitHub token used to delete the packages from the dev-* and ledgersmb_circleci-* packages is the same as the one used to delete the ledgersmb packages. I'm not aware that secrets can be scoped to single packages, so I'm expecting the token to work for the ledgersmb packages too.

[rohanmars]

I noticed that you haven't used the declarative token permissions setup. Did you then set these up within the project settings?
https://github.com/dataaxiom/ghcr-cleanup-action?tab=readme-ov-file#setup

[ehuelsmann]

Fixed the 404 with help of GitHub Support: the ledgersmb-docker repository needed to be granted "Admin" access for GitHub Actions in the package:

Going to provide GitHub feedback that a 403 - Forbidden would have helped me diagnose the problem.

[rohanmars]

Oh that makes sense, as you uploaded the package external to the github workflow the package security settings wasn't setup as it would have normally be done.

That would be good feedback that a 403 would be a better error, it would help future action users.

My 404 exception swallow (warning) fix is for a different error but will release that. Applied in your original case it would have produced 404's for all the packages, but would not have failed the action.

[rohanmars]

I've released v1.0.16/v1 which includes a new fix (1e3b9cd) to stop processing if multiple 404 occur. Basically the only time that would likely be the case is if the package doesn't have the correct access permissions. I've printed out a message to review the package security settings. A single 404 I've treated as a trasient error, which I've seen after 502 errors, but the underlying package was still deleted.

I'll close this issue for now.