Allow specifying custom build tags for the generated deepcopy files

[irbekrm]

It would be great if it was possible to specify custom Go build tags to be passed to deep copy generation, in the same way as it is currently possible to pass a custom header to be used, i.e

go run  sigs.k8s.io/controller-tools/cmd/controller-gen  \
	object:headerFile=<header-file-path> \
        object:buildTags="!plan9,!windows" \
        paths=./k8s-operator/apis/...

For the context - our Kubernetes custom resources live in a monorepo with our main application codebase, which is not Kubernetes specific. We build and run tests for various platforms, including plan9.

In our Kubernetes-specific code we need to import apimachinery library, but that contains code that cannot be built on plan9, i.e syscall.Errno here, so we exclude the Kubernetes-specific code from plan9 builds/tests with a !plan9 Go build tag.

Currently there is no way how to pass build tags to the generated deepcopy files, so we end up using a sed script to modify these files after they have been generated- this is a bit hacky and also prevents us from being able to generate deepcopy files using go generate which would be our preferred way.

I would be happy to PR a new flag to deepcopy generator for this.

[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

[sbueringer]

Sounds reasonable if it's doable without adding too much additional complexity (I'm not familiar with the current implementation)

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[irbekrm]

/remove-lifecycle rotten

[irbekrm]

/assign