Why does the circleci/aws-ecr@8.2.1 orb push multiple artifacts to a private repository?

[adam-alula]

Hello all. I use the aws-ecr@8.2.1 orb, specifically the build-and-push-image job to send Docker images to a private repository in the AWS ECR. When looking at my repository, I noticed that each execution of the build-and-push-image job has resulted in three artifacts in the repository, two that same size and one that is 0 bytes. Each artifact has a different digest.

When I call the job from within one of my own, the job parameters are similar to this:

steps:
  - checkout
  - aws-ecr/ecr-login
  - generate-tags
  - setup_remote_docker:
      version: 20.10.17
  - aws-ecr/build-and-push-image:
      extra-build-args: >-
        --ssh default
        --label somelabel=SomeLabel
      skip-when-tags-exist: true
      tag: "mytag"

In the logs I see similar to this:

#21 exporting to image
#21 exporting manifest sha256:aaaaaa 0.0s done
#21 exporting config sha256:bbbbbb 0.0s done
#21 exporting attestation manifest sha256:cccccc 0.0s done
#21 exporting manifest list sha256:dddddd 0.0s done
#21 pushing layers
#21 pushing layers 10.8s done
#21 pushing manifest for ********************************************/myrepo:mytag@sha256:dddddd
#21 pushing manifest for ********************************************/myrepo:mytag@sha256:dddddd 0.9s done
#21 DONE 33.9s

aaaaaa is the same size as dddddd
cccccc is sized 0 bytes
dddddd is correctly tagged

I do not know what bbbbbb represents

[adam-alula]

To clarify further dddddd is an Image Index in the ECR, and the other two artifacts cccccc and aaaaaa are Image types.

[rit1010]

While the source code is available for the ORB, one major limitation is that the command: that executes the shell script for build-and-push-image is just a single 3,500+ character line, so making it a little hard to see what is going on.

Within the executed script the ‘docker buildx build’ command is used and the output you are listing is coming from that command. So the exporting steps are just part of the local process of creating the image that you want to be built and pushed to AWS.

[maciejb]

Experiencing the same. Added concern is that this is then interpreted as a multi-platform image by AWS, and multi-platform images are not supported by Lambda, making the aws-ecr orb useless for publishing Lambda images for Docker. Not sure how to work around this… am I missing something?

[adam-alula]

I concluded similar as well, as far as multi-platform building goes. I think I can work around it for now, but I am unsure if those un-tagged artifacts are of any concern. It appears that the artifact marked as “Image Index” in the ECR is what I’m most interested in as it is what is retagged with the aws-ecr/tag-image job.

[maciejb]

Thanks for getting me to look at the aws-ecr/tag-image job! I was going to see if I could use it as a starting point for tagging the image I actually want tagged instead. But, when I ran this cli, it shows some more details about this 0-sized “image”. It is the attestation manifest. (and size isn’t 0, it’s 566 bytes, in my case).

{
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "schemaVersion": 2,
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:ab3355[...]",
      "size": 3348,
      "platform": {
        "architecture": "amd64",
        "os": "linux"
      }
    },
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:c0575c[...]",
      "size": 566,
      "annotations": {
        "vnd.docker.reference.digest": "sha256:ab3355[...]",
        "vnd.docker.reference.type": "attestation-manifest"
      },
      "platform": {
        "architecture": "unknown",
        "os": "unknown"
      }
    }
  ]
}

This leads to a simple solution! We can avoid creating this attestation by adding
extra-build-args: --provenance=false to the aws-ecr/build-and-push-image job.

[maciejb]

^ edit: the image is 0-sized, the manifest is what’s 566 bytes

[adam-alula]

Thank for your help @maciejb, --provenance=false is exactly what I needed. I am leaving a link to the documentation here for posterity. Provenance attestations | Docker Documentation