[Umbrella issue] Scaffolding enhancements

[Adirio]

Description

The following issue will group together all the different enhancements aimed to obtain a smoother file scaffolding system that improves redability, removes duplicate sections, avoids calling several methods multiple times, and centralizes functionality.

Some of the enhancements will be straight forward and will be directly implemented by a PR while others will have their own issue in order to contain the discussion. Please, keep comments in this issue just related to general topics related this issue or suggestions on which other enhancements to apply and use the respective issues or PR to talk about each of the enhancements.

Motivation

The main scheme followed by kubebuilder is the following:

1. Create a Cobra command and subcommands
2. This command creates a scaffolder for the specific command that:
   1. Sets default values
   2. Validates the provided input
   3. Creates the specific files

Issues found

• Some commands do not have an associated scaffolder and their scaffolding logic is done in the command itself (see cmd/webhook_1.go or cmd/webhook_2.go as examples).
• Validations are spread all accross the project. Some of them are done by the command and some by the associated scaffolder.
• Files are scaffolded with multiple non-needed fields (for example, ProjectPath is not required for any file and is provided to all, in pkg/scaffold/v1/crd/doc.go a field called Comments is not used, ...), information about the resource is kept outside the resource (GroupDomain, ResourcePackage), or stored in two places (Resource.Resource vs Plural).
• Resource is being validated by the scaffolders and by each file. This implies that, for example, for a single kubebuilder create api ... command the resource is validated 13 times.

Proposed solutions:

• Scaffolders for commands that do not have one should be created to keep the scaffolding logic in pkg/scaffold and not in cmd.
• Validation, unless directly related to the command, should be delegated to the scaffolder.
• Design interfaces for both scaffolders and files.
• Re-design the Resource struct to contain the fields that are outside: GroupDomain, Plural and ResourcePackage.
  • Determine if both Resource.Resource and (Resource.)Plural are needed or keep only one of them.

Related Issues and Pull Requests

Issues:

• [Scaffold enhancement] File interface #1226
• Split scaffold package #1264
• Template mixins #1358

Pull requests:

• Remove scaffolding fields that were not used #1219
• Move files inside a new directory #1221
• Add interface validation check for missing types #1248
• Named arguments for path formatting #1252
• Two-step resource creation #1255
• Split injecting fields and validating files #1265
• Validate resources for webhooks and tests #1266
• Include PROJECT file information into model.Universe #1313
• Offer a flag to change the image name #1314
• Fix unofficial way of handling already existing files #1316
• Move configuration file related types and functions to separate package #1325
• 🏃 Homogenize commands through Scaffolder interface #1330
• Move scaffold machinery to its own internal package #1339
• Move file related models to pkg/model/file #1340
• Group templates under a internal subpackage #1348
• Implement Wrapper interface for errors #1349
• Template mixins #1359
• Update files as part of the Scaffold.Execute #1375

More coming soon

/kind feature

[DirectXMan12]

awesome! thanks for working on this :-)

[DirectXMan12]

So, these are the names that exist according to CRDs:

• Resource Singular (.spec.names.singular, optional): singular resource name: prometheus. Defaults to lowercase kind in the CRD object.
• Resource Plural (.spec.names.plural): plural resource name: prometheis (Prometheus has weird pluralization rules)
• Resource Kind: (.spec.names.kind): Prometheus

So, we should have an internal representation of each of those. Without digging further, it's not clear what the different between Resource and Plural is supposed to be, but if I had to guess, it may have come from that distinction. At any rate, Resource.Resource should at least be renamed.