Allow to use the code-gen in vendorless projects

[cardil]

Background

At Knative project, we would like to get rid of the vendor directory (see knative/infra#134 for details). One of the things that block that is the extensive use of the Kubernetes code-generator, to be exact, the generate-groups.sh shell script.

Recently, the shell code in the Kubernetes has been rewritten a bit in the right direction (kubernetes/kubernetes#117262).

However, it still depends on the non-go shell scripts as the entry points, thus still requiring the use of vendor in the code. The usage of shell scripts isn't cross-platform.

Expected behavior

The Kubernetes code-gen should allow projects to leverage the go run ... syntax. With it, projects could use the code-gen even without any connection to Kuberentes code:

$ go run k8s.io/code-generator@v0.28.1 deepcopy \
  knative.dev/pkg/client knative.dev/pkg/apis \
  'duck:v1alpha1,v1beta1,v1' \
  --go-header-file "${REPO_ROOT_DIR}/hack/boilerplate/boilerplate.go.txt"

Or by managing the code-gen version in the project's go.mod file:

module knative.dev/serving

go 1.20

require (
	k8s.io/code-generator v0.28.1
)

and then running withing that project (notice the lack of the package version):

$ go run k8s.io/code-generator deepcopy \
  knative.dev/pkg/client knative.dev/pkg/apis \
  'duck:v1alpha1,v1beta1,v1' \
  --go-header-file "${REPO_ROOT_DIR}/hack/boilerplate/boilerplate.go.txt"

Ideas

Refactor into an entry point binary.

The K8s code-gen already has multiple binaries in the cmd/ directory, but we could add the entry point code-gen binary there, that will directly support the same arguments as the current kube_codegen.sh script. This approach is cross-platform.

Embed the shell script in Go

An easier solution would be to use an approach similar to knative/hack#222, so embedding the shell scripts into Go code (with //go:embed feature), and extracting it into some tmp/ directory.

[cardil]

/assign

[dprotaso]

It might be possible already

see: https://github.com/kubernetes-sigs/gateway-api/blob/1b14708b143e837fd94be97698ecbe0e6a4e058d/hack/update-codegen.sh#L64

[cardil]

@dprotaso: It might be possible already

see: https://github.com/kubernetes-sigs/gateway-api/blob/1b14708b143e837fd94be97698ecbe0e6a4e058d/hack/update-codegen.sh#L64

Yes, the specific generators are separate commands: https://github.com/kubernetes/code-generator/tree/master/cmd

However, this issue is about the shell wrapper files:

• https://github.com/kubernetes/code-generator/blob/7855250cd36120e10dc5bbf693ac4bdf42b7541f/kube_codegen.sh
• https://github.com/kubernetes/code-generator/blob/7855250cd36120e10dc5bbf693ac4bdf42b7541f/generate-groups.sh
• https://github.com/kubernetes/code-generator/blob/7855250cd36120e10dc5bbf693ac4bdf42b7541f/generate-internal-groups.sh

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[cardil]

/remove-lifecycle stale

[thockin]

Now that Go workspaces has landed in k/k, two things are changed:

1. you can run the individual k/code-generator/cmd/* tools with go run
2. their CLIs are improved so we don't need weird arguments and path manipulation

I'd prefer we obviate kube_codegen.sh rather than rewrite it. There are a few things that the kube_codegen.sh does that you would need to change to run the tools yourself. It does questionable grep to find files and then nukes them. If you know exactly which files/directories are in play, you can do that yourself.

[dprotaso]

thanks @thockin awesome work