Pinned but untagged images

[gowizzard]

Select Topic Area

Question

Body

Hello everyone, I have a question. I've been working with GitHub packages for the last few days. I have created an action which creates an image for linux/arm64 for a project with buildx. This also tags all images correctly and allows to display the manifest data. Now I have modified the action to create two images for linux/amd64 and linux/arm64.

The images can also be accessed via the packages and the two images are also displayed under OS, but unfortunately the images are also found under untagged images, although they seem to be assigned. Unfortunately, the manifest data is also missing from the image where the two OS versions are displayed. Does anyone know what this could be?

Here is my action:

name: GitHub Packages

on:
    push:
        tags:
            - 'v*.*.*'

env:
    REGISTRY: ghcr.io
    IMAGE_NAME: ${{ github.repository }}

jobs:
    build-and-push-image:
        runs-on: ubuntu-latest
        permissions:
            contents: read
            packages: write

        steps:
            - name: Checkout repository
              uses: actions/checkout@v3

            - name: Extract metadata (tags, labels) for Docker
              id: meta
              uses: docker/metadata-action@v4
              with:
                images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

            - name: Set up QEMU
              uses: docker/setup-qemu-action@v2

            - name: Set up Docker Buildx
              uses: docker/setup-buildx-action@v2

            - name: Log in to the Container registry
              uses: docker/login-action@v2
              with:
                  registry: ${{ env.REGISTRY }}
                  username: ${{ github.actor }}
                  password: ${{ secrets.GITHUB_TOKEN }}

            - name: Build and push Docker image
              uses: docker/build-push-action@v4
              with:
                  context: .
                  platforms: linux/arm64
                  push: true
                  provenance: false
                  tags: ${{ steps.meta.outputs.tags }}
                  labels: ${{ steps.meta.outputs.labels }}

Many greetings
Jonas

[ArdeshirV]

I think regarding the images being listed as untagged, one possible reason could be that the tags output from the docker/metadata-action step is not correctly capturing or passing the tags for the new images. Make sure that the tags output in the meta step captures all the relevant tags for both images (linux/amd64 and linux/arm64). You can check the output of the meta step by adding a debug log statement like run: echo "${{ steps.meta.outputs.tags }}". Verify if it includes the expected tags for both images.

As for the missing manifest data, it could be related to the provenance: false parameter you have set in the docker/build-push-action step. The provenance option controls whether to generate and include image provenance information in the manifest. Try setting provenance: true to include the manifest data when pushing the Docker images. This may resolve the issue with missing manifest data.

...
      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          platforms: linux/arm64,linux/amd64
          push: true
          provenance: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

[gowizzard]

Hi @ArdeshirV,

thank you for the tip, it may also be that generally the pinned images are always untagged as well? Or rather not?

I tried your tip with the provenance, unfortunately I get then also again another image for the OS unknown/unknown deshlab I have this on false gesezt. Are there any other options how I can set the manifest. Actually my action is almost the same as in the original example.

[daltonv]

@gowizzard you actually need to disable the provenance feature to get rid of this unkown/unkown image. It v4 of the build and push action it is on by default docker/build-push-action#773

[gowizzard]

@daltonv right, that's why I set it up that way in my first example, just wanted to show what happens since @ArdeshirV said I should enable this.

[daltonv]

Ah sorry I've been also looking into your original issue, but I had too many tabs open and forgot that detail about your issue.

Anyway I am having the exact same problem as you, but it kinda seems like this is how it is supposed to work aws/containers-roadmap#1596 (comment).

However this breaks any workflows where you want to automatically delete old images. Right now deleting the manifest image doesn't automatically delete the actual platform digest images.

It feels like this might be an improvement to either/both docker/build-push-action and docker/metadata-action so the platform digests are tagged.

I'm very much a docker beginner though, so maybe someone else has a good idea.

[f0rb]

Here is the official doc for merging multi-platform images into one with GitHub action: https://docs.docker.com/build/ci/github-actions/multi-platform/

I think the untagged images have no business with multi-platform.
I merged them successfully and tried to delete the untagged images, but the tagged images were broken and cannot be pulled.

[gowizzard]

I know the documentation, my action is also partly built like this. Unfortunately, in GitHub packages I get images without tags when I create multiple images for one version.

[piotrekkr]

Observed same behavior. There are always untagged images created when publishing new package version. Removing untagged breaks package download:

$ docker pull ghcr.io/piotrekkr/xxx:latest                   
latest: Pulling from piotrekkr/xxx
manifest unknown

When those untagged versions exist I have no problem pulling image from ghcr. I guess those need to stay.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬