Digest output is image ID, not RepoDigest

[jsok]

Troubleshooting

The output called digest is not in fact the digest that can be used to pull the image that was pushed to the repository.
The metadata output has the same ID listed as "containerimage.digest".

Behaviour

Steps to reproduce this issue

1. Use docker/build-push-action@v2 to build and push any image
2. View the outputs of the step

Expected behaviour

Tell us what should happen

The output named digest should contain the digest of the image, not the ID.

i.e. the output of docker inspect $IMAGE | jq .[].RepoDigests

Actual behaviour

Tell us what happens instead

The output named digest contains the Image ID, i.e. the output of docker inspect $IMAGE | jq .[].ID

Configuration

• Repository URL (if public): https://hub.docker.com/layers/163513701/sajari/docd/1.2.0/images/sha256-abe87bda82fdf472763c5782bd787154fd5196dbf37bb5b94b3c757df71f0de3?context=repo

DockerHub reports the Digest to be: sha256:abe87bda82fdf472763c5782bd787154fd5196dbf37bb5b94b3c757df71f0de3

• Build URL (if public): https://github.com/sajari/docconv/runs/3377464865?check_suite_focus=true

docker/build-push-action@v2 outputs a digest of sha256:e72b6e4b4ed5763c94bfde0320282c8a3125152d8f2325d015c37a01eed2a9b2

• Workflow definition: https://github.com/sajari/docconv/actions/runs/1148980570/workflow

Logs

Download the log file of your build and attach it to this issue.

1_Publish Docker image.txt

[crazy-max]

@jsok Can you rerun this workflow please? metadata output has been added recently (#412), I would like to see the output. Can you also add at the end of your workflow these steps:

      -
        name: Check manifest
        if: github.event_name != 'pull_request'
        run: |
          docker buildx imagetools inspect sajari/docd:${{ steps.meta.outputs.version }}
      -
        name: Inspect image
        if: github.event_name != 'pull_request'
        run: |
          docker pull sajari/docd:${{ steps.meta.outputs.version }}
          docker image inspect sajari/docd:${{ steps.meta.outputs.version }}

[jsok]

@crazy-max unfortunately I can't modify the workflow at this point in time, but I have re-run the workflow so that it pulls the latest version of this action.

The metadata shows the same image ID, not the digest reported by the remote.

See:

• https://github.com/sajari/docconv/runs/3583107491?check_suite_focus=true
  
• https://hub.docker.com/layers/sajari/docd/1.2.0/images/sha256-21c624dfe69e5cee36f23dfbe5ade4de371d537c4880ae5aa7e183caafb65887?context=explore
  

Maybe there's some overloading of the term digest going on here?

• Local images ID does not match registry manifest digest distribution/distribution#1662
• https://stackoverflow.com/questions/56364643/whats-the-difference-between-a-docker-images-image-id-and-its-digest

[jeffhollan]

Can confirm I am seeing the same thing. The digest output here does not match the digest shown in the registry (in my case, ghcr.io). So I'm thinking need to write a small action to get the right diget so I can use as an output to pull via digest

[tobsenll]

I also can confirm that issue with an image pushed to AWS ECR. As stated the output "digest" seems to something else (didn't investigate but I believe it's the image id). With that I can't use the output to use it in another step to pull the image

[k3nda]

I had a same problem.
I use workaround without using docker/build-push-action and use raw docker to build, push and output digest.

      - name: Build and push
        id: build-and-push
        env:
          IMAGE: ${{ env.REGISTRY }}/${{ env.REPOSITORY }}
        run: |
          docker build -f docker/Dockerfile -t ${{ env.IMAGE }} .
          docker push ${{ env.IMAGE }}
          echo "::set-output name=digest::$(docker inspect --format='{{index .RepoDigests 0}}' ${{ env.IMAGE }} | cut -d'@' -f2)"

[jsok]

There's no need to abandon docker/build-push-action, the current digest output is a reference to the locally built image, e.g.:

    - id: build
      uses: docker/build-push-action@v2
      with: { ... }
    - name: Get image digest
      id: digest
      run: echo "::set-output name=digest::$(docker inspect ${{ steps.build.outputs.digest }} | jq -r '.[].RepoDigests[0] | split("@") | .[1]')"

[jsok]

Having dug deeper on this issue, the digest output contains the remote digest if you run docker/setup-buildx-action before building.

If you do not call setup-buildx, then it seems to incorrectly populate digest with the local image ID as reported in the OP.

[lnhrdt]

I can also confirm that the digest is incorrect unless including the docker/setup-buildx-action step (I'm using GCP Artifact Registry).

The README says the step is not required but assists with multi-platform images, export cache. I don't have those use-cases so I left it out. Given how docker/build-push-action produces incorrect digests without it, I'm inclined to think of it as required!

Thanks @jsok for sharing the fix.

[mattmoor]

I just hit this putting together a small sample, and can also confirm that the workaround "fixes" this, but this feels like a pretty bad bug. Would the maintainers be receptive to a fix, if this is just a bandwidth problem?

[crazy-max]

Having dug deeper on this issue, the digest output contains the remote digest if you run docker/setup-buildx-action before building.

If you do not call setup-buildx, then it seems to incorrectly populate digest with the local image ID as reported in the OP.

Thanks for your feedback, will take a look and come back to you.

[ndeloof]

Suggested workaround unfortunately doesn't work on ECR:

> Setting outputs
  digest=sha256:be1fd4e317d06d7c6d82586152de642e527f1fc71e9f6514b90f40b5659a7e77
  metadata={
    "containerimage.digest": "sha256:be1fd4e317d06d7c6d82586152de642e527f1fc71e9f6514b90f40b5659a7e77"
  }

docker inspect xxx:foo | jq .[].RepoDigests
[
  "xxx:foo@sha256:aa7ec75a318f3e4a879e0939d97c900d82440b1aea26cebea04bb4a722109092",
]

Please note I'm using driver: docker, not sure about the impact?

[crazy-max]

docker/buildx#975 should fix this issue. You can try it with:

      -
        name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1
        with:
          version: https://github.com/crazy-max/buildx.git#moby-remotedgst

[kpcyrd]

The official docker-publish.yml template still links to here:

      # Workaround: https://github.com/docker/build-push-action/issues/461
      - name: Setup Docker buildx
        uses: docker/setup-buildx-action@79abd3f86f79a9d68a23c75a09a9a85889262adf

Since this github issue is closed, can this workaround be removed?

[suntong]

The official docker-publish.yml template still links to here:

Since this github issue is closed, can this workaround be removed?

+1

Can anyone confirm please?

[ChihweiLHBird]

I saw the official workflow is still linking to this issue and I have no idea what happened. Is the workflow way correct for handling everything now?

[crazy-max]

Since this github issue is closed, can this workaround be removed?

Not needed anymore.

I saw the official workflow is still linking to this issue

Not sure what you mean? I don't see any reference to this issue in our code base.

I'm locking this issue as it has been solved but feel free to open a new one if it still happens. See also #906 (comment).