Enable hermetic build for operator #619
Conversation
When running in a hermetic environment (no access to the network), the build was failing because of our Makefile trying to install controller-gen at build time. As this line was added by the operator-sdk, we would like to avoid modifying it. It's actually useful in local builds, to make sure we're using the right tools. We also want to avoid using a different Makefile or Dockerfile for Konflux. This commit provides a way to allow using the same process for building locally and in our CI. It mimics the behavior we have in CPaaS, relying on having controller-gen defined as a dependency in our go.mod file. I'm adding a script that runs "go run" for controller-gen, and place it where the Makefile expects to find the actual controller-gen binary 'make' will find that and skip the install of the tool, then call that script in place of the actual tool whenever needed. - in the context of a local build, "go run" will download and build the tool, just like it would if you used "go install", then run it as expected. - in the context of Konflux in a hermetic environment, "go run" will find the controller-gen sources pre-fetched by cachi2/Hermeto, and build it from there. Signed-off-by: Julien Ropé <[email protected]>
They fails when running in hermetic builds where there is no network. The build command will actually perform the download, if needed, when running outside of the CI, so those lines don't seem to be necessary anyway. Signed-off-by: Julien Ropé <[email protected]>
Set the flag and enable the gomod manager for prefetching. As no RPM is installed during build, this is all we need to the controller. Signed-off-by: Julien Ropé <[email protected]>
littlejawa
force-pushed
the
enable_hermetic_build_for_operator
branch
from
cdf50ac to
52d0ce4
Compare
Dockerfile
Outdated
| @@ -13,6 +13,10 @@ COPY api api/ | |||
| COPY config config/ | |||
| COPY controllers controllers/ | |||
|
|
|||
| # Copy our controller-gen script to work around hermetic build issues | |||
| # See comments in the script itself for more details. | |||
| COPY controller-gen bin/controller-gen-v0.17.2 | |||
There was a problem hiding this comment.
When does that version number change? My understanding is that this needs to be kept consistent with go.mod, how do we document that? Also asking because controller-tools release v0.17.3 has been out for three weeks now.
There was a problem hiding this comment.
Updating it is part of the work we do on each release cycle. It's been kind of a manual process up to now.
With Konflux, we are offered an automated dependency check with PRs that update our go.mod dependencies (that's from Mintmaker), so we might get it like that.
Updating it requires changing both go.mod and Makefile. And now this Dockerfile.
There's no clear documentation about it, maybe there is room for improvement...
At the very least, I can add a comment here.
When we update the controller-tools version, we need to update go.mod, Makefile and Dockerfile, making sure they're all in sync. This commit tries to automate that for container builds: the Dockerfile will create an environment variable with the version found in go.mod, and use that for setting up the controller-gen script, and calling 'make' with that version. For local builds, where only the Makefile is used, the default version found in the Makefile still needs to be updated. But for container builds, the value in the Makefile will be overriden, and always in sync with go.mod. Signed-off-by: Julien Ropé <[email protected]>
|
@littlejawa: all tests passed! Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
- Description of the problem which is fixed/What is the use case
Enable hermetic build for the controller manager.
- What I did
gomod dependencies are managed by cachi2/Hermeto, enabling it is pretty simple.
I had to work around the controller-gen problem (again). Taking inspiration from the way we do it in CPaaS, but trying to avoid using different Dockerfile/Makefile for local and CI builds.
I'm adding a new script that
makewill use in place of the regular controller-gen. This script uses "go run" to run the tool.In the context of a local build, this results in downloading/building the file as usual.
In the context of a hermetic build, with the dependencies pre-fetched, it will build the tool based on the prefetched sources.
- How to verify it
For a local build: run
podman build .For CI: the Konflux task in this PR must pass.
You can look at the logs too:
Fixes: KATA-3796