Hello all. I use the email@example.com 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:
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
cccccc is sized 0 bytes
dddddd is correctly tagged
I do not know what
To clarify further
dddddd is an
Image Index in the ECR, and the other two artifacts
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.
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?
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
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).
This leads to a simple solution! We can avoid creating this attestation by adding
extra-build-args: --provenance=false to the
^ edit: the image is 0-sized, the manifest is what’s 566 bytes
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
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.