Project file with all user input data

[camilamacedo86]

Description

Ensure that we are storing all input data in the PROJECT file.

Motivation
I am maintainer like to ensure that we have stored all input data used to scaffold the projects by the user so that I could propose a subcommand/plugin to help users migrate from a plugin version X to X+1 since would be possible scaffold the project from the scratch. Also, it might be helpful in many scenarios to tooling the scaffolds.

Mor info: See: #1644 (comment)

What is missing to be stored

• Webhooks data
• resource/controller=[true|false]

/kind feature

[camilamacedo86]

Hi @estroz, @joelanford, @DirectXMan12, @pwittrock I am pushing it for v3+plugin for we have the chance to discuss it and try to achieve it for the release if we agree on that. Looking for your inputs as well.

[estroz]

hasResource and hasController for the resources

Maybe only hasResource? If you're building a type library you would set --controller=false --resource=true, so we'd probably want to set hasResource: true or types: true field for its GVK. Conversely, one major reason you would have --resource=false --controller=<true|false> set is if you're using an external type; the config can store an external type path as something like external: <import path> (see #1772) instead of controller: true.

from the init owner and license

These are already captured in hack/boilerplate.go.txt so these don't need to be tracked in the config.

[camilamacedo86]

Hi @estroz,

These are already captured in hack/boilerplate.go.txt so these don't need to be tracked in the config. 👍

Totally agree. Good point.

Maybe only hasResource?

Currently, the GVK is only persistent on the PROJECT file if the resource is true. So, how the allow all combinations shows that the best way is we store both booleans as use the api one to check if the api was or not scaffolded. See my suggested solution #1849. PS.: I think it will also be beneficial for we address the scenarios raised/discussed in #1772. I hope that you liked it.

[estroz]

Prior to releasing v3.0.0, the config spec for version 3-alpha needs to be stabilized. A few changes have been added to or are proposed for 3-alpha. To summarize:

• Added resources[].crdVersion and resources[].webhookVersion when --crd-version and --webhook-version are set, respectively (⚠️ (go/v3-alpha) default to v1 CRDs and webhooks #1644)
• Add resources[].api and resources[].controller when --resource and --controller are set, respectively (✨ (go/v3-alpha) store data info to know if the controller and/or api were scaffolded #1849)
• Add resources[].webhooks for defaulting, validating, and conversion webhooks (✨ store all config info (go/v3-alpha)  #1696)

These additions are being made (not intentionally) without considering what they'll look like together, but should be. Perhaps a redesign of resources is in order instead of tacking on new fields to the version 2 implementation. Something like the following:

version: 3-alpha
resources:
- api: # api contains all important information from `create api`
    group: my.domain
    version: v1
    kind: CronJob
    crdVersion: v1
    resourceTypes: true # If 'api/v1/cronjob_types.go' was created
    controller: true # If 'controllers/cronjob_controller.go' was created
  webhook: # webhook contains all important information from `create webhook`
    webhookConfigVersion: v1
    types:
    - validating # If `webhook.Validator` was implemented
    - mutating # If `webhook.Defaulter` was implemented
    - conversion # If `--conversion` was set

The above design groups fields by create subcommand, which is logical given the expected kubebuilder command flow of init -> create api -> create webhook.

@Adirio @DirectXMan12 @pwittrock thoughts on making a drastic design change prior to the v3.0.0 stable release?

[Adirio]

My thoughts but written by you. 100% agree. And 100% in favor of omiting as many of these fields as possible if they are default values.

[joelanford]

Each plugin can define its own flags, so would the plugin also control these fields? If so, that kind of points to these fields being stored under the plugin configuration somewhere, possibly.

Either way, I feel like this is a pretty major change right as we're trying to stabilize v3. I would vote we hold this out of v3 and make it a candidate for v4.

[estroz]

Each plugin can define its own flags, so would the plugin also control these fields?

Yes. These fields are intended to be general enough such that any plugin can make use of them. If they aren't used by a plugin, then they're omitted from the config, so the user will never have to worry about them.

Either way, I feel like this is a pretty major change right as we're trying to stabilize v3

I am worried about that. Perhaps we should punt on this issue, #1696, and #1849 for now and go with what exists in the current spec, since none of the fields mentioned in this issue or those PRs are necessary for v3.0.0 features.

[Adirio]

What do you think about the following model:

version: 3-alpha
domain: my-domain.com
crdVersion: v1beta1
webhookVersion: v1beta1
apis:
- resource:
    group: Ships
    # version omitted means v1
    kind: Boat
    # plural omitted means Boats
    # domain omitted means my-domain.com (see line 2)
    # path omitted means it is not an external type
  definition:
    # version omitted means v1beta1 (see line 3)
    namespaced: true
  # controller omitted means false
  webhooks:
    # version omitted means v1beta1 (see line 4)
    types:
    - validating
- resource:
    group: Animals
    version: v2
    kind: Sheep
    plural: Flock
    domain: my-animals.com
    path: "github.com/owner/repo/apis/animals"
  controller: true

Templates allow methods that return a single value to be used in templates as if they were fields: {{ .Resource.ImportAlias }}. You can also provide methods with 2 output arguments if the second one is an error, in which case if the method returns an error it will be returned by template.Execute function. We can use them for ImportAlias and GroupPackageName that don't need to be saved in the project config file as they are computed from other fields but they need to be provided to the templates.