Align version of dependencies when Fuzzing

[pjbgf]

The fuzz testing should be running against the same dependency versions that are used during testing and release of controllers, for improved reliability of the results.
In projects that depend on libgit2 (e.g. source-controller and image-automation-controller) this is even more so, as both git2go and libgit2 must be within a specific version range for them to work together.

The current implementation manages the fuzzing test code into a secondary go module (i.e. ./tests/fuzz) to avoid contaminating the
main go.mod with numerous dependencies that are not required for the controllers to run. This resulted in a few adhoc solutions which are not currently fully aligned across the projects.

The main change required is for go mod tidy to be replaced with a go get -d github.com/AdaLogics/go-fuzz-headers in projects in which the fuzzing code is copied back into the main modules:

• pkg
  https://github.com/fluxcd/pkg/blob/main/tests/fuzz/oss_fuzz_build.sh#L37
• notification-controller
  https://github.com/fluxcd/notification-controller/blob/main/tests/fuzz/oss_fuzz_build.sh#L48
• kustomize-controller
  https://github.com/fluxcd/kustomize-controller/blob/main/tests/fuzz/oss_fuzz_build.sh#L41
• image-reflector-controller
  https://github.com/fluxcd/image-reflector-controller/blob/main/tests/fuzz/oss_fuzz_build.sh#L29
• helm-controller
  https://github.com/fluxcd/helm-controller/blob/main/tests/fuzz/oss_fuzz_build.sh#L33

In some projects the fuzz test runs on its own module, meaning that it requires a copy of the current project go.mod on top of the removal of go mod tidy:

• source-controller
  https://github.com/fluxcd/source-controller/blob/main/tests/fuzz/oss_fuzz_build.sh#L57-L81
• image-automation-controller
  https://github.com/fluxcd/image-automation-controller/blob/main/tests/fuzz/oss_fuzz_build.sh#L92

This should no longer be required once #2417 lands.

[ilanpillemer]

Hi @pjbgf , why is this a good first issue? I am looking around for good first issue to look at.

[pjbgf]

Hey @ilanpillemer, this is a straightforward change that needs to be consistent across all repositories.

The first part is pretty much ensure that we remove go mod tidy on all the files linked above. Then ensure that all the dependencies are still in place - in some cases this will require a go get....

Feel free to propose a PR and tag me for review.

[ilanpillemer]

@pjbgf I did a grep on the first file in the list (for pkg) and I got three lines with go mod tidy.
Would this change happen in all three places or just the first one (as you just mention the first line in the description above)?
Based on your explanation above, I believe all three should be replaced. Just verifying I am understanding.

tests/fuzz/oss_fuzz_build.sh:37:go mod tidy
tests/fuzz/oss_fuzz_build.sh:51:go mod tidy
tests/fuzz/oss_fuzz_build.sh:60:go mod tidy

[pjbgf]

@pjbgf I did a grep on the first file in the list (for pkg) and I got three lines with go mod tidy. Would this change happen in all three places or just the first one (as you just mention the first line in the description above)? Based on your explanation above, I believe all three should be replaced. Just verifying I am understanding.

@ilanpillemer that's correct, in the pkg those 3 instances relate to three separate go modules.

[ilanpillemer]

@pjbgf as far as I could understand when eyeballing the sh files for tasks 6 and 7, the go.mod file is already being copied, so no changes were needed in that respect for tasks 6 and 7 if that assumption is correct based on that quick glance.

[pjbgf]

@ilanpillemer I think the only additional thing was the go get -d for the current project on image-automation-controller, but you already added that. 👍

[ilanpillemer]

@pjbgf I didnt use the -d flag though when I added it.

[pjbgf]

@ilanpillemer that should not be a problem, as it is simply updating the reference against "itself" locally.
Besides, once #2417 lands most of this logic will become redundant.

[ilanpillemer]

@pjbgf I didn't think it was a problem, as I was assuming it was ephemeral either way. Just mentioned it, in case there was some edge case funny that was not intuitive to me.