Parsing image references with both tag and sha fails

[martin-sucha]

name.ParseReference does not handle Docker image references like ubuntu:latest@sha256:868fd30a0e47b8d8ac485df174795b5e2fe8a6c8f056cc707b232d65b8a1ab68 (which Docker supports). This causes GoogleContainerTools/kaniko#535.

This could probably be fixed by adding some logic to ParseReference or implementing #78.

[scothis]

I just bumped into this myself.

My naive attempt at a fix was to embed Tag inside Digest instead of Repository, and to test for a tag when parsing the digest. This almost works, but a few of the reflective test fail as it adds a default :latest tag to the output image name. If I can get it working I'll send a PR.

[jonjohnsonjr]

I'm curious what the expected semantics of this reference are. Do you pull the image by the tag and error out if the digest is different? Is the tag just there as a "comment" that we can safely ignore? I'm leaning towards the latter to avoid breaking people when tags change.

[scothis]

In my local tests with docker pull the tag is ignored. Haven't looked at the spec yet.

[briandealwis]

I've hit this with Skaffold, which catenates an image reference (like xxx:latest) with the sha256 digest. This is then passed along in a Kubernetes manifest which is happily accepted.

      containers:
        image: gcr.io/gcp-dev-tools/bdealwis/xxx/microservices-kubernetes-demo-customer:02e6676@sha256:852935558bef6251c18c0c69c79eafa002d1e24cff3599dd499e6e33a201f58d
        name: microservices-kubernetes-demo-customer