-
Notifications
You must be signed in to change notification settings - Fork 1
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
sigstore image deleting #8
Comments
I've added sigstore cosign support to the action: dataaxiom/ghcr-cleanup-action@6448a08 and released it in v1.0.12 uses: dataaxiom/[email protected] |
@rohanmars thank you very much for noticing! This current use was just personal, but also I was planning to take what I learned to apply in the larger ublue-os org, so I'm glad you caught this issue! I'll update to the new action and see how it goes. |
As you had the 90 day older-than option it limited any impact to older images. In that case the sig images where treated as standalone images so where processed as top level image in the keep-n-tagged count processing. From your recent run it does appear that there are some orphaned sig images (older then 90 days). It would be useful to see how it runs over a few days, assuming you have images which will be included in the 90 day bucket on these new runs. I'm working on a new delete-orphaned-images option to the cleanup action, which will cleanup sha256-xxxxx images (cosign/referrers) if they don't have their parent anymore. I'll commit that in a few days most likely. I also added some status progress messages on the manifest loading stage, which gives a better indication that things are processing. I had noticed on another repo which had 5000 images that it appears hung while it was actually doing work. I was happy to see your job finished successfully after 3 hours. The long time is due to the api throttling github enforces. |
I also see a weird scenario in your latest log where some of the sig are are not included in the 90 days. That would be an unusual usecase where the image/sig publishing was occurring exactly at the 90 mark. I need to investigate that further and review how the action handles that. |
Actually I think the logic is okay after all. But I'll watch your repo over the next few days and check the logs. The extra dangling sig image that was in you last run is likely from running with the older version without cosign support. In your case that stale sig will eventually get cleaned up with the keep-n-tagged mode. But the new feature I'm adding delete-orphaned-images would also clean it up. |
Awesome! I had planned to let this run at least a week or more anyway before I implement it elsewhere. I'm happy to be your test repo for new features. |
That's great, haha I've just released v1.0.13 which includes a new 'delete-orphaned-images' option, which if set to true will delete the orphaned .sig image. Would be useful to see if that option cleans up your orphaned sig in your registry. It's meant as more of a one time thing. And in your case that sig image would eventually get deleted as it's treated as a standalone image as it has no parent image. |
That's great. It looks like it did clean up those orphaned sig images (plus some untagged images that had been pulled into scope). Looks good. Thanks! |
I'm going to let this run at least another week before I do any more implementation. Keep going with these new features! I love it! |
Good plan. |
Hi there
I happened to notice your cleanup task. It seems to be using a variant of the sigstore that I don't think it accounts for in the ghcr-cleanup-action.
deleting package id: 147574249 digest: sha256:c46a7c3c703da49ee911ad26aa7b50f9832fce2f886989f7ff14ac19fe450970 tag: sha256-f01382b35af6bdb9629002a2e60b5d969f7a5e1cfeaea933453b4cb898ead696.sig
In that case the action doesn't look for the suffix ".sig" so I don't think it would be making the correct association between the parent image and sig image. The usecase it currently accounts for (github attestation action) just uses a tag "sha256-f01382b35af6bdb9629002a2e60b5d969f7a5e1cfeaea933453b4cb898ead696" without the .sig. I think I need to add this usecase.
You might want to hold off further execution until I can validate that.
Rohan
The text was updated successfully, but these errors were encountered: