internal/pkg/scaffold: add group.go scaffold to prevent deepcopy parse errors

[estroz]

Description of the change: scaffold a pkg/apis/<group>/group.go file.

Motivation for the change: The following error is generated by the gengo parser:

$ operator-sdk generate openapi
W0507 16:56:26.785419   21221 parse.go:239] Ignoring child directory github.com/test-org/operator/pkg/apis/<group>: No files for pkg "github.com/test-org/operator/pkg/apis/<group>"

which doesn't look great. While we could skip reporting the error if it has that form, we might accidentally skip a valid error. Adding a package file to the group package corrects the error without any other changes.

Closes #1502, closes #1546

[joelanford]

LGTM

[lilic]

Thanks for this!

Just curious would this have any effect on already existing operators when they add a new api? Otherwise lgtm!

[estroz]

@lilic @joelanford the SDK will scaffold pkg/apis/<group>/stub.go if one does not exist. I've also added a check for existence of any go files in pkg/apis/<group>; if one exists, stub.go is not scaffolded since it is unnecessary. PTAL.

[joelanford]

Makes sense. Still LGTM.

[lilic]

Thanks for clarifying!! 👍

[hasbro17]

As discussed offline I think it's better if we don't add a new scaffold just to suppress an upstream warning.
This is a noticeable change in a user's project and the reason for it will not be immediately obvious.
Plus if the warning is suppressed later on upstream then we will have this scaffold for no reason.

We should first check if it's possible to address this upstream. And if not then probably suppress it in our CLI.
If we look out for this exact warning then hopefully there shouldn't be any unintended side effects of suppressing other future warnings.
Either way adding a new scaffold for this should be a last resort if at all necessary.

[estroz]

@hasbro17 this is actually an "issue" with go/build, and it looks like the intended behaviour is to error.

From one of the issue comments:

This issue appears to extend further - build.Import with build.FindOnly should return the directory path resolved for an import, even if there are no Go files in the directory, but this does not seem to be the case with Go modules.

This is exactly what k8s.io/gengo is doing, which is used by controller-tools, and by dependency us, to generate CRD's. If the intended behaviour is indeed to error if there are no go files in a package, by implication the correct way to structure packages is to always have at least one go file in them, right? So perhaps this is the best solution.

[lilic]

Coming back to this, while I was at the workshop a lot of users were super confused by the warning and came to me asking if this is a problem or not. So would be good to bypass this in a way, or suppress it just to avoid confusion IMHO.

[hasbro17]

LGTM after nit since there's no other way to suppress this and it's causing confusion for end users.

@estroz Also mention this in the CHANGELOG in the Added section that we now scaffold group.go so gengo warnings are suppressed.
It's a (minor) change visible to end users so it's best to point out why.

[estroz]

/test sanity