Action produces large number of untagged images

[Time0o]

I have tried all measures I can think of to prevent this but in some cases (it is not clear to me which those are) this action produces a number of untagged images that from their history seem to be more or less identical to existing ones. I have this setup:

    - name: Extract image metadata                                                  
      id: metadata                                                                  
      # 369eb59 = v5.6.1                                                            
      uses: docker/metadata-action@369eb591f429131d6889c46b94e711f089e6ca96         
      with:                                                                         
        images: ghcr.io/my_org_my_image                               
        tags: |                                                                     
          type=raw,pattern={{version}},value=${{ steps.version.outputs.version }}

    - name: Build and push image
      # 4f58ea7 = v6.9.0
      uses: docker/build-push-action@4f58ea79222b3b9dc2c8bbdd6debcef730109a75       
      with:
        context: image
        file: image/Dockerfile    
        tags: ${{ steps.metadata.outputs.tags }}
        labels: ${{ steps.metadata.outputs.labels }}
        push: true
        outputs: type=image,name=ghcr.io/my_org/my_image,push=true 
        platforms: linux/amd64
        provenance: false

Here is the result for one of my packages:

I'm hesitant to file this as a bug because maybe there's a sensible explanation? But without multi arch build or provenance this just can't be right, can it?

[Aetherinox]

I was hoping when I read this title, my issue would have a solution here. I pushed an image, and I just cleared out two full pages of tagless images.

[crazy-max]

There should be an untagged manifests left behind assuming the new build is different. Tag-less stick around until you delete them on GHCR. Other registries might just hide them like Docker Hub.

Also can you show the logs of Build and push image step or link to your repo?

[Aetherinox]

Sure thing, here is mine: https://github.com/Aetherinox/docker-base-alpine/pkgs/container/alpine-base

Here is the last executed workflow: https://github.com/Aetherinox/docker-base-alpine/actions/runs/13527171597

Right now I've been playing with settings, and I still have two tagless SHA being generated:

 provenance: false
 sbom: false

Your action is executed in the steps labeled:

• name: 📦 Build & Push (linux/amd64)
• name: 📦 Build & Push (linux/arm64)

Workflow source: https://raw.githubusercontent.com/Aetherinox/docker-base-alpine/refs/heads/docker/alpine-base/.github/workflows/deploy-docker-github.yml

[crazy-max]

@Aetherinox Thanks

So looking at previous jobs: https://github.com/Aetherinox/docker-base-alpine/actions/workflows/deploy-docker-github.yml

Like #24: https://github.com/Aetherinox/docker-base-alpine/actions/runs/13527105896

It builds and push: https://github.com/Aetherinox/docker-base-alpine/actions/runs/13527105896/job/37800374191#step:13:437

#33 exporting to image
#33 exporting manifest sha256:4c3f12c7186d6cc6a11b41af915ad2960a45f7e198ff69fb46b389a1959d326f done
#33 exporting config sha256:098ebccf6438f116ee620978fd5fa8f23de67734e486481154b603645e7d6c72 done
#33 pushing layers
#33 pushing layers 1.0s done
#33 pushing manifest for ghcr.io/aetherinox/alpine-base:3.20-amd64@sha256:4c3f12c7186d6cc6a11b41af915ad2960a45f7e198ff69fb46b389a1959d326f
#33 pushing manifest for ghcr.io/aetherinox/alpine-base:3.20-amd64@sha256:4c3f12c7186d6cc6a11b41af915ad2960a45f7e198ff69fb46b389a1959d326f 0.3s done
#33 pushing layers 0.1s done
#33 pushing manifest for ghcr.io/aetherinox/alpine-base:latest@sha256:4c3f12c7186d6cc6a11b41af915ad2960a45f7e198ff69fb46b389a1959d326f
#33 pushing manifest for ghcr.io/aetherinox/alpine-base:latest@sha256:4c3f12c7186d6cc6a11b41af915ad2960a45f7e198ff69fb46b389a1959d326f 0.3s done
#33 pushing layers 0.1s done
#33 pushing manifest for ghcr.io/aetherinox/alpine-base:latest@sha256:4c3f12c7186d6cc6a11b41af915ad2960a45f7e198ff69fb46b389a1959d326f 0.1s done
#33 DONE 2.5s

And also: https://github.com/Aetherinox/docker-base-alpine/actions/runs/13527105896/job/37800374191#step:14:434

#31 exporting to image
#31 exporting manifest sha256:43b022b4ad2c9a840b35689775589e78823ea739eaea60404bdf1484f954cb9f done
#31 exporting config sha256:ed8554b628f0c504a37329b1545a39215b3983b1b5ac8a2559472c833ecf858b done
#31 pushing layers
#31 pushing layers 0.8s done
#31 pushing manifest for ghcr.io/aetherinox/alpine-base:3.20-arm64@sha256:43b022b4ad2c9a840b35689775589e78823ea739eaea60404bdf1484f954cb9f
#31 pushing manifest for ghcr.io/aetherinox/alpine-base:3.20-arm64@sha256:43b022b4ad2c9a840b35689775589e78823ea739eaea60404bdf1484f954cb9f 0.3s done
#31 pushing layers 0.2s done
#31 pushing manifest for ghcr.io/aetherinox/alpine-base:latest@sha256:43b022b4ad2c9a840b35689775589e78823ea739eaea60404bdf1484f954cb9f
#31 pushing manifest for ghcr.io/aetherinox/alpine-base:latest@sha256:43b022b4ad2c9a840b35689775589e78823ea739eaea60404bdf1484f954cb9f 0.3s done
#31 DONE 2.2s

So:

• alpine-base:3.20-amd64 with digest sha256:4c3f12c7186d6cc6a11b41af915ad2960a45f7e198ff69fb46b389a1959d326f
• alpine-base:latest with digest sha256:4c3f12c7186d6cc6a11b41af915ad2960a45f7e198ff69fb46b389a1959d326f
• alpine-base:3.20-arm64 with digest sha256:43b022b4ad2c9a840b35689775589e78823ea739eaea60404bdf1484f954cb9f
• alpine-base:latest (again) with digest sha256:43b022b4ad2c9a840b35689775589e78823ea739eaea60404bdf1484f954cb9f

We can see both of them in untagged as expected: https://github.com/Aetherinox/docker-base-alpine/pkgs/container/alpine-base/versions?filters%5Bversion_type%5D=untagged

Because latest run #25: https://github.com/Aetherinox/docker-base-alpine/actions/runs/13527171597 pushes the same tags with new manifests:

https://github.com/Aetherinox/docker-base-alpine/actions/runs/13527171597/job/37800581108#step:13:439

#33 exporting to image
#33 exporting manifest sha256:afa7a5993914a47e1d404bbd05f960fbaf8d26d899c0ced0b86d3c2857de4454 done
#33 exporting config sha256:2e43cdfcbfef77ba3527cac1ba1338b818de0dcfeafae15f4a93d7a3a4e70ea9 done
#33 pushing layers
#33 pushing layers 0.9s done
#33 pushing manifest for ghcr.io/aetherinox/alpine-base:3.20-amd64@sha256:afa7a5993914a47e1d404bbd05f960fbaf8d26d899c0ced0b86d3c2857de4454
#33 pushing manifest for ghcr.io/aetherinox/alpine-base:3.20-amd64@sha256:afa7a5993914a47e1d404bbd05f960fbaf8d26d899c0ced0b86d3c2857de4454 0.4s done
#33 pushing layers 0.1s done
#33 pushing manifest for ghcr.io/aetherinox/alpine-base:latest@sha256:afa7a5993914a47e1d404bbd05f960fbaf8d26d899c0ced0b86d3c2857de4454
#33 pushing manifest for ghcr.io/aetherinox/alpine-base:latest@sha256:afa7a5993914a47e1d404bbd05f960fbaf8d26d899c0ced0b86d3c2857de4454 0.3s done
#33 pushing layers 0.1s done
#33 pushing manifest for ghcr.io/aetherinox/alpine-base:latest@sha256:afa7a5993914a47e1d404bbd05f960fbaf8d26d899c0ced0b86d3c2857de4454 0.1s done
#33 DONE 2.6s

https://github.com/Aetherinox/docker-base-alpine/actions/runs/13527171597/job/37800581108#step:14:434

#31 exporting to image
#31 exporting manifest sha256:1c7ef0c461fadfdced2ffb700aec32ea3e3067269575aac8a63146ec096b0020 done
#31 exporting config sha256:a7800ed1cfdec1fd6b2140df6871e6ad076dcd3ad0849314f3cf67df2dfdedd4 done
#31 pushing layers
#31 pushing layers 1.0s done
#31 pushing manifest for ghcr.io/aetherinox/alpine-base:3.20-arm64@sha256:1c7ef0c461fadfdced2ffb700aec32ea3e3067269575aac8a63146ec096b0020
#31 pushing manifest for ghcr.io/aetherinox/alpine-base:3.20-arm64@sha256:1c7ef0c461fadfdced2ffb700aec32ea3e3067269575aac8a63146ec096b0020 0.3s done
#31 pushing layers 0.1s done
#31 pushing manifest for ghcr.io/aetherinox/alpine-base:latest@sha256:1c7ef0c461fadfdced2ffb700aec32ea3e3067269575aac8a63146ec096b0020
#31 pushing manifest for ghcr.io/aetherinox/alpine-base:latest@sha256:1c7ef0c461fadfdced2ffb700aec32ea3e3067269575aac8a63146ec096b0020 0.5s done
#31 DONE 2.5s

So I think it behaves correctly.

[Aetherinox]

The double tagged one I can fix.

But the question I don't understand is; if it's pushing the ones with proper tags; then why is it pushing another copy without the tags? Shouldn't those also have tags since they match the SHA of the tagged ones?

Or is their an incorrect part of my workflow which is triggering this behavior? Not sure I get where to start looking as to the root cause why it behaves like this.

The ultimate goal is just for it to release two images, both tagged.

---

Edit: Yeah, I see why it was double-tagging latest. Was a copy/paste error. So the double :latest is gone now. I was defining the latest tag, and also setting a global "flavor" for latest. So they were conflicting.

And I see now, the two untagged are coming from the previous workflow

[crazy-max]

Found this related topic https://github.com/orgs/community/discussions/26716#discussioncomment-3253024 that says tag-less manifests are shown in GitHub UI so this is expected and not related to the action.

[Time0o]

Found this related topic https://github.com/orgs/community/discussions/26716#discussioncomment-3253024 that says tag-less manifests are shown in GitHub UI so this is expected and not related to the action.

How is that related to this issue? It explicitly says pushing another identical image should not leave behind an untagged one.

[crazy-max]

@Time0o Per https://github.com/orgs/community/discussions/26716#discussioncomment-3253024:

There should be an untagged version left behind assuming the new build is different.

If you have a repro with public repo, we can look at it.