Publish a ko builder with GCB's kubectl magic

[mattmoor]

Basically this, but ko: https://github.com/GoogleCloudPlatform/cloud-builders/blob/master/kubectl/kubectl.bash

cc @imjasonh

[imjasonh]

Unless we support Go modules (#269) this is going to be gross, along the lines of the go builder, which ln -ses /workspace to a location that it then specifies as $GOPATH. If we support/require Go modules we can build the ko builder with ko, based on an image that has kubectl installed.

The kubectl image is also pretty thoroughly tied to GKE, and it's huge because it installs all of gcloud basically just for auth and so it can call gcloud container clusters get-credentials -- I think we can do better.

[mattmoor]

Hmm, that issuing is using Go modules here. I thought Go modules worked with ko, but were slower because of IsSupportedReference going from O(1) to O(something more than 1)?

I'll play around with them on my kodemo repo...

[jonjohnsonjr]

The naive change to support go modules makes IsSupportedReference ~O(number of files on filesystem) if I understand correctly. We can try populating an index with the packages package to get around that...

[mattmoor]

Yeah, Go modules definitely work, but we should look at speeding up IsSupportedReference.

[mattmoor]

Hmm, watch isn't working for some reason.

[mattmoor]

Ok, I know what the issue is, it's my hack for determining the enclosing package when we see things change, hopefully nbd.

[mattmoor]

FYI: google/go-containerregistry#359

[jonjohnsonjr]

@imjasonh what does this have to do with go modules? Is this still relevant?

[imjasonh]

The reason modules support was relevant is because without it the source had to be made available in $GOPATH/src/<importpath>, which isn't going to be the case in GCB or Tekton (or GitHub Actions). gcr.io/cloud-builders/go did a bunch of funny business to symlink `/workspace` into the correct location in GOPATH. But that won't be necessary with modules. Now that `ko` supports modules the source can be in `/workspace` and can still be built. A `ko` image only needs to have `go` and `kubectl`, plus the logic in kubectl.bash above to provide GKE creds. We can get this done by having a base image that's `FROM golang`, installs `kubectl`, renames it to `kubectl_real`, then has a `kubectl.bash` named `kubectl` on PATH which sets up creds then calls `kubectl_real`. It's all a terrible hack. Oh it also needs the GCR cred helper to push images. And that's only enough to use ko against GKE/GCR.

[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.