Conversation
f768146 to
2855a46
Compare
3c0a08e to
84a6d48
Compare
| digest = "sha256:ccaef5ee2f1850270d453fdf700a5392534f8d1a8ca2acda391fbb6a06b81c86", | ||
| image = "gcr.io/distroless/base", | ||
| platforms = ["linux/amd64","linux/arm64"], |
There was a problem hiding this comment.
When I run the following command, I see different digests for the AMD64 and ARM64 images:
docker manifest inspect gcr.io/distroless/base \
| jq --raw-output \
'.manifests[] | select(.platform.os == "linux") | {arch: .platform.architecture, digest}'What allows you to specify one digest here and assume that the resulting image will work for both of these machine architectures?
There was a problem hiding this comment.
crane has a digest command that lets you query the digest by running crane digest <IMAGE>. alternatively, you could specify tag and reproducible = False attributes and replace the attributes according to the warning message oci_pull will print.
There was a problem hiding this comment.
This all makes more sense to me today. With Using a combination of crane digest, docker manifest inspect, and GCP's Web console to inspect the GCR entries, I now see how we're able to point at an image that contains a manifest list, with several entries, each for a different combination of operating system and machine architecture.
With the docker manifest inspect command, it's not possible—or at least I couldn't figure out a way—to see the image digest for the image nominated by the tagged name. It dumps the manifest list, but doesn't tell you the digest of the image containing that manifest list. Using the crane digest command closes that gap.
Thank you for the suggestion, @thesayyn.
The file list of c-ares 1.15.0 is used for 1.16.1 since the following files are the same: 1. modules/c-ares/1.16.1/patches/add_build_file.patch 2. modules/c-ares/1.15.0/patches/add_build_file.patch And add_build_file.patch is adapted from https://github.com/grpc/grpc/tree/master/third_party/cares. I have tried to find c-ares version 1.16.1 in grpc project. A search of grpc project commit log shows that the most relevant thing is commit bdb3f860649bb4c136ba36bad3d9363fccbd29fa which mentions '-DgRPC_CARES_PROVIDER=package with c-ares 1.16.0 overrides'. My guess is that grpc has upgraded c-ares from 1.15.0 to 1.17.2 directly. I built c-ares 1.16.1 with `buildconf` on macOS. The resulted Makefile has the following two file list: 1. CSOURCES: C++ source files. 2. HHEADERS: C++ header files. A comparison of CSOURCES with cc_library srcs attribute shows that some source files are missing. ares_getopt.c is unneeded ares_getopt is not include in CSOURCES. It is included in SAMPLESOURCES. So this commit deletes it. This commit also adds the missing C++ source files. A comparison of HHEADERS with cc_library hdrs attribute shows that hdrs has three extra files: 1. ares_config.h 2. config-win32.h 3. ares_getopt.h ares_getopt.h will be deleted together with ares_getopt.c. Since I am not sure of the reason why the other two files exist, they are kept untouched. Fix #77 update update
No description provided.