Disconnect Operator Support to Init for an Existing Go Project

[kensipe]

Feature Request

Describe the problem you need a feature to resolve.

Operator SDK supports 2 approaches for init.

1. Init of a new project that does not have a go.mod
2. Init of a project where a go.mod exists. (this is true for upstream kubebuilder as well)

The second (go.mod file exists) model was intended to support a new go.mod file, not an existing go project with a populated go.mod file. This case can cause issues as raise in #4027. This model of development is not recommended.

Describe the solution you'd like.

It is recommended that we fail validation if specific files exists during init. IF go.mod exists, init should fail with a message that indicates that init only supports the creation of new projects. We should upstream this behavior to kubebuilder for consistency and support.

/language go

[camilamacedo86]

IMO we can still be allowing the go.mod. Also, by addressing it we identified that has other files that we need to allow such as .gitignore in the directory. see the PR made to address it; kubernetes-sigs/kubebuilder#1738

[camilamacedo86]

I am closing this one since it was tracked only for we do this change in upstream.
Now, when SDK supports the v3-alpha plugin implementation it will be solved.