Combination of KO_DOCKER_REPO=kind.local and ko publish --bare is not working

[SaschaSchwarze0]

We have a script that is building a couple of images where we need to specify the full image name and therefore usually use it like this:

TARGET_IMAGE=${TARGET_IMAGE:-our.registry/somenamespace/someimage}"

KO_DOCKER_REPO="${TARGET_IMAGE}" ko publish --bare --tags=sometags ./cmd/some-command

While wanting to debug something I quickly ran this script with TARGET_IMAGE set to kind.local. And that's not working. It produces an image like kind.local:digest and that's not working. It actually fails when it tries to run ctr images tag.

I think in case of publishing to KinD and using bare, ko will need to name the image in some way, for example kind.local/ko-output so that it can work.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.

[nitinmohan87]

I am running into this problem as well. I am not able to customize the image name when loading images to KinD. The image names could not be customized with the --bare option.

$ KO_DOCKER_REPO=kind.local/my-repo/foo ko build ./foo --bare
2024/03/04 10:56:50 Loading kind.local:4fb763f1785990540ed037b63f4369211c53fea361d628be4e73edb0331962c8
2024/03/04 10:56:51 Loaded kind.local:4fb763f1785990540ed037b63f4369211c53fea361d628be4e73edb0331962c8
2024/03/04 10:56:51 Adding tag latest

However, setting the KO_DOCKER_REPO with ko.local prefix builds the image with the correct name

$ KO_DOCKER_REPO=ko.local/my-repo/foo ko build ./foo --bare
2024/03/04 10:59:50 Loading ko.local/my-repo/foo:4fb763f1785990540ed037b63f4369211c53fea361d628be4e73edb0331962c8
2024/03/04 10:59:51 Loaded ko.local/my-repo/foo:4fb763f1785990540ed037b63f4369211c53fea361d628be4e73edb0331962c8
2024/03/04 10:59:51 Adding tag latest

I don't understand why setting KO_DOCKER_REPO with kind.local prefix has a different behavior.

[nitinmohan87]

It looks like this PR addresses this issue but has been closed - #1027