Customized image name

[vincent-pli]

For now, there is two way to identify name/url of image:

1. With -P: The image name should be gcr.io/foo/github.com/bar/baz/cmd/blah
2. Without -P: gcr.io/foo/blah

In a docker hub based repository it's not friendly,
Firstly, option 1 is not work, since url of docker hub based repository is repo-address/user-name/repo-name:tags.
Then if I want push images from several projects, for example: knative, tekton, they all has controller, the only solution to different them is add tags.

So I wonder if could supply one more option to make the url of image as project-pakcage, like gcr.io/foo/bar-blah

[vincent-pli]

Seems it's a unattractive idea, so we still need use docker tag to change the image 😭

[jonjohnsonjr]

So there's the default namer, which adds a md5 hash of the repo, -P which preserves, and -B which just has the last component of the path. I'm not super opposed to adding a fourth one, but it's unclear how you'd do this in a general way that will always look nice...

[vincent-pli]

I'm afraid you are right.
But I still want to proposal:

1. Since the URI of golang project should be ${GOPATH}/src/domain/group/project/cmd/entry
   so what about group-project-entry

2. Just use dash to join the import path as image name:
   git.luolix.top-tektoncd-pipeline-cmd-creds-init

[k15r]

Wouldn't it make sense to have an option that allows you to just define the image name yourself? No logic required, just like the -t flag?

[jonjohnsonjr]

Wouldn't it make sense to have an option that allows you to just define the image name yourself? No logic required, just like the -t flag?

This makes sense for a single image, but when publishing multiple images (e.g. ko apply) you'll end up publishing everything as the same name... which is fine, but a little confusing.

I wonder if we could do something with go templates.

[winmillwill]

I wonder if this is a case where ko could be strict but aligned with best practices and at the same time give users an easy target to hit. ko operates on executables, and (IIUC) they're always supposed to be in cmd unless the project has exactly one top-level main.go and no mains in cmd. So, the image name for a flat repository (docker, quay) could always be the "basename" of the go import used in a kube manifest: it's the name of the repo if you have one top-level main.go, and it's the package if the package is in cmd.

so,

KO_REPOSITORY_NAME=quay.io/getdopeorg
github.com/my-dope-org/validate-pod-is-dope/main.go
        -> quay.io/getdopeorg/validate-pod-is-dope:{latest,{{md5}}}
github.com/my-dope-org/operate-dope-reboots/cmd/dope-reboot-operator
        -> quay.io/getdopeorg/dope-reboot-operator:{latest,{{md5}}}
github.com/my-dope-org/operate-dope-reboots/cmd/dope-reboot-agent
        -> quay.io/getdopeorg/dope-reboot-agent:{latest,{{md5}}}

I can't prove that part of the project name ending up as part of the executable name as a kind of "stutter" is conventional, let alone best practice, but if it affords "containers as invisible infrastructure", then maybe it becomes best practice (for people with that need)?

For bonus points, maybe ko could interpret replace directives in go.mod so that users didn't have to necessarily actually move files around? I don't know if that's difficult and/or adds value relative to having users move the files around and add the opposite of the replace directive they would have added if ko had this feature. I also don't know if the replace directive affords any leverage for simplifying the handling of needs for "flat and stutter executable" vs nested image repository.

[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. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[jonjohnsonjr]

FYI, #234 may partially address this issue, and Matt revived the discussion a bit in mattmoor/mink#279.