helm backend should at least WARN (maybe error?) if the user supplied image is not found

[cburroughs]

Is your feature request related to a problem? Please describe.

$ cat dependencies src/deployment/BUILD 
cat: dependencies: No such file or directory
#Overrides the `image` value for the chart using the target address for the first-party docker image.
helm_deployment(dependencies=["src/chart"],
                sources=["common-values.yaml"],
                values={"image": "src/docker:docker"})
$ cat dependencies src/deployment/BUILD 
cat: dependencies: No such file or directory
#Overrides the `image` value for the chart using the target address for the first-party docker image.
helm_deployment(dependencies=["src/chart"],
                sources=["common-values.yaml"],
                values={"image": "src/docker:whale-typo"})
$ ./pants dependencies src/deployment:deployment
src/chart:chart

😿

Describe the solution you'd like
If the user specifically says "use this image", but said image isn't found, pants should warn or error out or something

Describe alternatives you've considered

Additional context
#18345
https://github.com/cburroughs/example-python/tree/17da445368d145f22693f86d4157895609968922

[lilatomic]

I think there are a few wrinkles because Pants target addresses are also valid docker images (unless the address is absolute):

1. it could refer to a valid normal docker image (eg "bitnami/wordpress:6.5.4")
2. it could be a version of a Pants docker container that isn't the latest one. For example, we might have a docker container src/my-app that's currently at "2.0.0" but a deployment that's looking for "src/my_app:1.0.0"

I think we could add a toggle to warn if the image name (src/docker) looks like a folder on disk or if the path is obviously a Pants target (//src/docker:whale-typo or :my-app)

[lilatomic]

There are a couple of easy cases:

• If the registry component of the docker image doesn't exist as a file/folder on disk, the Get for MaybeAddress is a ResolveError.
• If the target name component of the address is incorrect, the MaybeAddress is an Address that doesn't point to a valid docker container.
• Relative addresses begin with ./ and cannot be docker images

but there's a hard one

• If the repository component of the docker image exists as a file on disk, we cannot distinguish this. For example, a top-level folder "python" will confuse an image python:3.10. I think that might actually not be much of a problem for global docker containers. (ex, my original though was grafana, since people might have that as a top-level folder for their dashboards. But the repo is grafana/grafana. I think it's more plausible for "library" images, like python. In theory you could mute the error by using the full name of the repo&registry with docker.io/library/python:3.10.)

I thought that there would be trouble with different versions of an image where the docker repository component is a path in the repo. For example, if myproject/myapp:docker is the address of a docker container with repo myproject/myapp, specifying an image as myproject/myapp:1.1.1 looks like a target. But I think this is likely not a problem, since you'd most likely be using a private registry (so the image would have to be something like ghcr.io/myproject/myapp, and it would be weird to put all of your projects into a folder for your container registry). So it the affected people would be using dockerhub, using Pants to build and deploy images, and using images that looked like normal targets (I think it's more plausible that they would put all of their code into a folder named the same as the root of their docker registry).

I think we could add a toggle to the warning (like python-infer.unowned_dependency_behaviour and document the workaround of including the docker.io registry and call it good.

[lilatomic]

Oh, there's also the case where the typo happens in the path. my-project:app instead of myproject:app. I actually can't think of a good way to resolve that.