Add project type to support hybrids SDK projects

[camilamacedo86]

Description
Add project type to support hybrids SDK projects

Motivation
Closes: #879

[camilamacedo86]

/assign @mengqiy
/assign @DirectXMan12

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: camilamacedo86
To complete the pull request process, please assign directxman12
You can assign the PR to them by writing /assign @directxman12 in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mengqiy]

/hold
I'm not sure if this is the right way to approach this, since using this approach plugins will be in-tree. That is not the goal.

cc: @droot @DirectXMan12

[mengqiy]

I'd suggest keep this flag hidden from the users until it's ready.
You can achieve that with cmd.Flags().MarkHidden("flag name")

[camilamacedo86]

Done 👍

[camilamacedo86]

/hold
I'm not sure if this is the right way to approach this, since using this approach plugins will be in-tree. That is not the goal.

I think that would make sense we have the info in the PROJECT file which defines the spec/attributes of it. IHMO it is a simple and easy solution to allow hybrid ones. So, based on the PROJECT file we could do any further implementation. Also, in POV it could keep simple do things as for example, allow us to scaffold the Makefile according to the type and add the plugins and etc, allow the plugins know how to dealing with the code, allow the tool know how to dealing with the project and etc .. WDYT?

cc: @droot @DirectXMan12 @mengqiy

[DirectXMan12]

cc @joelanford @justinsb

do we currently not store initial plugin info? Agree with camilla here -- it seems like we should store the general project structure for later so that you don't have to specify --plugin/--pattern/etc every time (for types where that makes sense)

[k8s-ci-robot]

@camilamacedo86: The following test failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
pull-kubebuilder-e2e	36a8183	link	/test pull-kubebuilder-e2e

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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. I understand the commands that are listed here.

[camilamacedo86]

Hi @mengqiy and @DirectXMan12,

Could we move forward so with this one? Would you like to change anything in the way that it was done?

[camilamacedo86]

@mengqiy it is rebased with the master now in order to pass in the prow tests.

[camilamacedo86]

HI @mengqiy,

@DirectXMan12 agreed with this change as well here; #1171 (comment). WDYT, could we move forward with this one?

[joelanford]

@camilamacedo86 @DirectXMan12 @hasbro17

We are working on a proposal that will address this and should have something posted soon. In the meantime, the working POC is at https://github.com/joelanford/kubebuilder-exp if you want an early look.

The idea is:

1. Introduce kubebuilder CLI plugin interface that the CLI uses to decide how to scaffold projects, APIs, and webhooks.
2. Each plugin defines its project version. Project versions must be unique in the set of plugins registered in a binary, and ideally they would be globally unique to make different binaries more interchangeable. (i.e. "2" always means kubebuilder's Go version 2 scaffold).
3. The existing Go scaffolders built into kubebuilder will continue to be versions "1" and "2".
4. Other plugins can define other versions. For example, operator-sdk's helm and ansible plugins could use "helm:1" and "ansible:1"

I'm not opposed to introducing a new ProjectType field if that makes more sense. That probably needs more discussion.

I'm in favor of leaving this on hold, pending our proposal.

[DirectXMan12]

closing as per the feature branch and related discussion.

[k8s-ci-robot]

@camilamacedo86: PR needs rebase.

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.