Operator in hermetic build

When trying to build the operator in an hermetic environment, we have an issue where the Makefile uses controller-gen to generate some of the needed files.

controller-gen then needs to be installed at build time, and it fails because there is no network access.

NOTE: this is not our design choice - downloading the tool at build time is something that operator-sdk added to the Makefile. Because of that, I assume that all operators have the same problem to solve.

NOTE: I did not face this (yet?), but according to the discussions, controller-gen is just one of many dependencies that operators have. I'm focusing on controller-gen because it is the issue I have right now

We can add the dependency in the go.mod file, but this is not enough: the prefetch step will get the sources, but the binary is still not there, and needs to be installed or built separately.

I've looked at the konflux-users channel and confirmed multiple teams have the same issue, each finding their own solution.
A good summary can be found on this discussion on slack

References to other operators that have been onboarded with Konflux:
https://issues.redhat.com/browse/KFLUXMIG-352
https://issues.redhat.com/browse/KFLUXMIG-314
https://issues.redhat.com/browse/KFLUXMIG-305
https://issues.redhat.com/browse/KFLUXMIG-302

At the moment, I have identified the following options, but I'm not sure this list is comprehensive.

Build the controller-gen tool ourselves

We can build controller-gen as a separate component in a pre-build phase, and the resulting image can be used to retrieve the binary during the operator's build.
The SBOM is then correctly generated as controller-tool effectively becomes a component of our project.

I think some teams have gone this route already. I'm a bit concerned that we ask every team to build the same tool separately though. It is like asking us to build our own compiler.

Use a pre-generated image made by another team

This would benefit all teams that need to build an operator from Konflux.

Some links related to that:

• https://issues.redhat.com/browse/KONFLUX-5108
• The github repo: https://github.com/konflux-ci/operator-sdk-builder
• Images built from there are here: https://quay.io/repository/konflux-ci/operator-sdk-builder?tab=tags
  (no update since ~6 months?)

I think we can use this image, but it doesn't contain controller-gen. Maybe we should add it?
As mentioned above, controller-gen is a dependency that operator-sdk has pushed on us, it would make sense to make it live alongside it (even if operator-sdk itself is being deprecated).

If we use that, we need to make sure this image is marked as a component to be released for our product - so that SBOM is happy, and no exception needed.
See https://issues.redhat.com/browse/KONFLUX-298

Another ticket was created as part of the discussion on slack, but maybe it is a duplicate of the above?
https://issues.redhat.com/browse/KONFLUX-7007

This is a nice solution, but it needs to get the versions of tools we need.
How about operators that have different versions to support? Do we need separate versions of this image?
Should this be followed/maintained by OpenShift people?

If for some reason we diverge from the versions used in this repo, an alternative solution is to fork it and build it ourselves (which brings us back to option #2).

Run the controller-gen from the sources fetched by cachito

This is the way we're doing it in CPaaS.
First, we need to add controller-gen as a dependency of our project, inside the go.mod file, so that the sources are pre-fetched by cachito.

Then as part of the Dockerfile, we don't call our "make build" command, but copy the steps of the build process into the Dockerfile.
When it comes to generating the manifests, we run the command:

go run sigs.k8s.io/controller-tools/cmd/controller-gen object:headerFile="hack/boilerplate.go.txt" paths="./..."

Which, in the context of cachito, builds and run the controller-gen tool from the pre-fetched sources.

I don't like having a different Makefile/Dockerfile for Konflux and for local builds.

Trying a different approach than what we do in CPaaS:

• make a script that runs "go run ..." as above, with all parameters it receives
• place that script in the location where the Makefile expect is

This should prevent the install, and still run things as expected: in a local build, "go run" will download/build the tool as usual. In a hermetic environment, it would build it from the pre-fetched sources (assuming we have controller-gen dependency correctly defined in our go.mod file, which we do).