Jason Hall

The cosign version is also old: https://github.com/GoogleContainerTools/distroless/blob/1a3e90ffe07519e8586f37dc956f93aeb87e09b1/cloudbuild.yaml#L53 I'm not sure it's possible to sign the platform-specific images before they're pushed (I'm also not sure it's useful), but I _think_ it...

`docker manifest inspect` helpfully inserts a trailing newline, which isn't there when you push it. So: ``` _digest=$(printf "%s" "$(docker manifest inspect ${_image})" | sha256sum -) cosign sign ${_image}@${_digest} docker...

The cc train rolls on with a cc @loosebazooka

`ko run` does a `ko publish` then `kubectl run --attach`, which itself is basically a `kubectl run` then `kubectl attach`. It doesn't look like `kubectl attach` handles ctrl+c by killing...

> I don't think we document `ko run` anywhere, and maybe we should hide it... it's a bit janky. I'd be fine with that. I'm not sure if @mattmoor uses...

I don't think `ko run` is very widely used -- I don't think I've ever used it myself -- but it does seem like `--namespace` would be a useful addition,...

As for why `ko apply --namespace` is `(DEPRECATED)`, that's because we want to have users just pass flags directly through to kubectl instead of having them be flags on `ko...

We've decided to keep `ko run` around at least for now, so if you or anyone reading this is interested in adding it, that could be nice. I'd probably want...

I have no particular problem with this. I wonder how we'd like to let users configure this. In `.ko.yaml` probably, per-importpath?

Honestly I'm fine with just removing it, I just want to give people an opportunity to tell us why they think it's load-bearing for them, if it is. I'm not...