Skip to content
New issue

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

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

Already on GitHub? # to your account

Removing untagged images can damage tagged images #63

Closed
lukasz-mitka opened this issue May 17, 2023 · 11 comments
Closed

Removing untagged images can damage tagged images #63

lukasz-mitka opened this issue May 17, 2023 · 11 comments

Comments

@lukasz-mitka
Copy link
Contributor

lukasz-mitka commented May 17, 2023

Running action like so

      - name: Delete old untagged containers
        id: untagged
        uses: snok/container-retention-policy@96e897805acf21aa2ebc21fdf8e04c879e7daf9d # v2.0.1
        with:
          image-names: image
          account-type: org
          org-name: ${{ github.repository_owner }}
          cut-off: 2 weeks ago UTC
          untagged-only: true
          token: ***

Can damage tagged images:

$ docker pull ghcr.io/org/image:tag
tag: Pulling from org/image
manifest unknown

GitHub Support response:

The way Docker publishes images changed recently. Instead of publishing images directly, it now publishes a hidden image alongside a manifest. You can see this below where it says OS / Arch (2). The (2) represents the hidden image and manifest.
This has the unfortunate consequence of breaking tools that detect untagged images (because the hidden image isn't tagged directly). When the hidden image is deleted, it leads to this manifest unknown error. Unfortunately there isn't an obvious fix for this.

provenance is enabled by default since docker/build-push-action@v4
My workaround is to disable it:

 - uses: docker/build-push-action@v4
   with:
     provenance: false
     ...

Solution for already broken images: republish them

@sondrelg
Copy link
Member

Do you propose we update the README of this action to notify users about this behaviour, or do you think this is something we can fix by changing the implementation?

@lukasz-mitka
Copy link
Contributor Author

Do you propose we update the README of this action to notify users about this behaviour, or do you think this is something we can fix by changing the implementation?

My understanding is there's no fix currently, but that's based on GH support answers, didn't verify it myself.

So I propose adding a warning in readme and pinning this issue for the time being.

@lukasz-mitka
Copy link
Contributor Author

lukasz-mitka commented Jun 2, 2023

I have confirmed that disabling provenance (provenance: false) fixes the issue.

Workaround:

 - uses: docker/build-push-action@v4
   with:
     provenance: false
     ...

@sondrelg
Copy link
Member

sondrelg commented Jun 4, 2023

That's very helpful. Would you be interested in creating a PR too @lukasz-mitka?

@lukasz-mitka
Copy link
Contributor Author

No, sorry.

@mering
Copy link

mering commented Oct 31, 2023

Duplicate of #43

igaw added a commit to igaw/linux-nvme-build-img that referenced this issue Nov 29, 2023
When removing untagged images it damages the docker manifest.
The workaround is to disable the attestations.

Link: snok/container-retention-policy#63
Signed-off-by: Daniel Wagner <dwagner@suse.de>
@rohanmars
Copy link

I fixed this in a new project. https://github.com/dataaxiom/ghcr-cleanup-action, without the providence workaround above. It requires uploading a temporary manifest to unlink the tag, then that can be deleted.

@sondrelg
Copy link
Member

sondrelg commented May 13, 2024

Please see #43 (comment) @rohanmars. Any reason you don't think that would work?

@rohanmars
Copy link

Yes skipping sha's is what I did essentially not to not delete the platform specific images linked from the manifest. It gets more complicated when you want to support multiple tags to the same multiarch image and when you want to actually delete the multiarch image. In the delete case you would want to include these digests.

@sondrelg
Copy link
Member

For when you actually want to delete the multi-arch image, I would have thought that you'd be fine as long as you always make sure not to delete the SHAs associated with the current tag. Any old untagged images can then be deleted safely - assuming you're passing in the SHAs of all multi-arch images. Is there anything else that needs to be taken into account?

@sondrelg sondrelg mentioned this issue Jun 23, 2024
@sondrelg
Copy link
Member

The latest release adds a skip-shas input argument, which can be used to protect against deleting multi-platform images. Please see the new section in the readme for details, and let me know if anything is unclear.

The migration guide for v3 is included in the release post 👍

If you run into any issues, please share them in the issue opened for tracking the v3 release ☺️

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

No branches or pull requests

4 participants