Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prune job deleted image that wasn't supposed to be deleted. #95

Open
hgibsonqb opened this issue Jul 29, 2024 · 5 comments
Open

Prune job deleted image that wasn't supposed to be deleted. #95

hgibsonqb opened this issue Jul 29, 2024 · 5 comments

Comments

@hgibsonqb
Copy link

Hi,

I configured the prune job with a cut-off of 2 weeks and a keep-last-n value of 10. The running image was the third latest, and it was 20 days old. Neither the prune dry-run nor the actual prune said this image was deleted and also github ghcr.io reported the image as being there. However, after the prune, pulling the image no longer worked, I got a "manifest not found" error.

Any idea what might be causing this?

This is prune job v3.0.0.

@sondrelg
Copy link
Member

Does your image have multiple versions uploaded to support multiple platforms/architectures?

@hgibsonqb
Copy link
Author

Kind of? One is linux/amd64 (which we actually use) and the other is unknown/unknown

@sondrelg
Copy link
Member

There's not really great support for these types of images in the GitHub packages API. How to handle it, plus the background of the issue is described here: https://github.com/snok/container-retention-policy?tab=readme-ov-file#safely-handling-multi-platform-multi-arch-packages.

That said, I'm planning on integrating a real fix for this into the action. I think we've finally found an approach that will work, without too many trade-offs. See #90 for details. I don't have too much time on my hands these days, but you can track that issue if you want to know when that's done 👍 Contributions are also welcome, of course!

@hgibsonqb
Copy link
Author

The work around in the example only gets the multi-platform shas for the latest version of the image right? So it wouldn't work with keep-last-n?

@sondrelg
Copy link
Member

The action does not (yet) solve the problem. Instead it gives users a way to solve it themselves. The example given requires you to explicitly declare every image version, so it's not a very ergonomic way to solve it, and wouldn't just work for keep-last-n, no :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants