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/[email protected] 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

[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

[thockin]

Should we close this now?

[cardil]

/close

Yes. Thanks

[k8s-ci-robot]

@cardil: Closing this issue.

In response to this:

/close

Yes. Thanks

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.