Configurable scaffolding behaviour

[negz]

/kind feature

Recently a discussion about desired testing practices began in #952. It was pointed out that kubebuilder is inherently opinionated, and that these opinions extend to testing patterns. This is a reasonable approach; kubebuilder cannot be all things to all people.

In the Crossplane project we use kubebuilder and friends to avoid reinventing various wheels that are required to build Kubernetes controllers. We love kubebuilder and agree with most - but not all - of its decisions. When projects disagree with parts of kubebuilder they can simply scaffold out what they need and remove or change the rest. This is feasible when a small set of contributors are scaffolding and adding new types, but I worry that it doesn't scale.

We've recently added a developer guide for Crossplane API types and controllers that effectively states "use kubebuilder to scaffold your types", but there are a few exceptions:

1. We ask that contributors use the --controller=false flag to avoid generating a controller scaffold, since we provide a set of baked in types that satisfy Reconciler.
2. We ask that contributors disregard kubebuilder's recommended testing patterns and use ours.

I'm still catching up with the changes in 0.2, but it seems like 1. implies 2 today. There's a general theme here though in that it would be really nice to be able to opt out of certain kubebuilder patterns as a project without depending on contributors reading documentation and learning that they need to pass in certain flags. Perhaps this would look like a .kubebuilder config file that encodes preferences like --controller=false at a project level.

[DirectXMan12]

we're working on a plugin system to address some stuff like this. It currently takes "the universe" of the scaffolding and gets to output it's own version of "the universe", so it should address this situation.

For instance, you could just have the crossplane plugin that drops the controller (or scaffolds out something with your own types) and sets up your testing setup.

[DirectXMan12]

The initial pieces just went in -- see the plans and discussion in #943

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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/test-infra repository.