You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, GetDigest does an API call to translate any image reference into a digest. But if the image reference contains a digest and not a tag, is there a reason why the digest should not be parsed out of the image reference, thus saving an API call?
I mean, the caller of this API is by definition specialized to do a tag resolution operation, so that caller could just … not use this?
I don’t have a strong opinion on whether the “is the reference to resolve a tag or a digest” ideally belongs inside GetDigest or inside a caller, if that condition really had to exist.
It’s more that I have a hunch that this might indicate some other design issue in the caller, trying to maintain a reference->digest mapping that doesn’t need to exist, or something like that. Or, well, a caller invoking GetDigest with a digest already known might very well be a natural outcome of some abstraction layering, where that information gets lost…, and preserving that information would be more trouble than it’s worth.
Of course, I know nothing at all about the caller, so take this just as a thing to possibly explore, something you quite likely have a firm and well-justified opinion on.
Currently,
GetDigest
does an API call to translate any image reference into a digest. But if the image reference contains a digest and not a tag, is there a reason why the digest should not be parsed out of the image reference, thus saving an API call?image/docker/docker_image.go
Line 120 in 0e74274
The text was updated successfully, but these errors were encountered: