@rn @deitch I've just noticed that make show-tag for alpine/guestfs will show the tag for a given arch, which is useful, but we don't have any way to get the tag used for the multi-arch manifest... which is really what I want to lint! any suggestions?

Also this will fail as it found that the test-ns image is out of date and needs building and pushing.

@dave-tucker wrote:

make show-tag for alpine/guestfs will show the tag for a given arch, which is useful, but we don't have any way to get the tag used for the multi-arch manifest

I think (I have been digging more deeply into alpine lately) because they use different algorithms:

• lkt pkg <command> gets its image tag by using the git tree hash of the directory. It relies on anything that might change the final image being picked up by a change in the source. For the most part, that works except for:
• tools/alpine gets its image tag by calculating the sums of the packages in the image itself (and a few other things). I am assuming this is because the builds depend on apk add <pkg>, and that is not always 100% reproducible, even for the same version of alpine.

If you want to see it in action, I have a small PR open to simplify it and the build process. It doesn't change the logic, just easier to get at and have alpine carry it along the way, see #3650 . Actually, that is so small and simple that it should get approved and merged quickly.

@deitch, tools/alpine should be the only package which pulls stuff from the network without out us knowing exactly which bits and that's why it always will have a special case. All other package are either build exclusively from linuxkit/alpine:<hash> or, if they download some from the network we tend to ckeck out a specific immutable git commit or, when we download, verify the hash. So the content hash from the package directly completely describes the contents of the package.

I don't disagree. I don't know what the story is with the guestfs one.

I think tools/guestfs is x86 only and for some reason is not linuxkit pkg based (possibly because we did not have the right version in alpine)...well it also pulls a random debian:stretch...