Separate the API into its own module

Trivy Operator v0.21.2 introduced a ton of new indirect dependencies, which makes using github.com/aquasecurity/trivy-operator v0.21.2 as a Go module quite large. I have a project that utilizes the v1alpha1 API for making requests with client-go into the native Go types/structs. But I noticed that upon updating my module for trivy-operator, my binary size more than doubled. I then noticed my indirect dependencies added dozens of new entries, and downgraded to Trivy Operator v0.21.1, before all of these dependencies started getting pulled in. But realistically, I just need the API structs in a module with their deepcopy methods to make GET requests for those Kinds with client-go.

My project is located at https://github.com/starttoaster/trivy-operator-explorer for reference.

I believe tools like mine bring value to trivy-operator and its maintainers by making it easier for cluster maintainers to parse the custom resource reports trivy-operator generates, making it more likely people use your tools. In that way, I think it benefits you (as well as me of course) to have a separate go module for the API structs.

I understand that unused pieces of the trivy-operator package shouldn't end up getting linked by the Go compiler, but interestingly, the linker seems to be pulling in an additional 60MB of content from >v0.21.1 of trivy-operator even though I'm just using the API structs. I find it difficult to believe I'm actually using an additional 60MB of source code from just the API, so I'm not sure what else could be going on here, to be honest. But if you take a look at the diff of the pull request I linked, all those indirect dependencies are coming from the latest versions of trivy-operator, which is kind of crazy.

aquasecurity / trivy-operator

Separate the API into its own module #2243