set Follow to false when retrieving logs

[jrhunger]

Description

Set Follow=false when retrieving logs from completed job.
Using Follow mode in this case is unnecessary because:

• Follow is used to wait for additional logs that may come from the container
• By the time the operator is collecting the container logs, the container has already completed and will not generate more logs

In cases where the underlying node has resources (fsnotify handle) exhaustion this causes the logs to return an error after the base64 data "failed to create fsnotify watcher: too many open files", and trivy fails to process that scan job due to "illegal base64 data".

I tested this simple change in a cluster that was having the issue, and the operator processed and deleted all the completed scan jobs that were previously being continuously re-processed with base64 failures.

Related issues

• Close needlessly using follow option when retrieving logs of completed job #2264

Checklist

• I've read the guidelines for contributing to this repository.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[jrhunger]

I have signed the CLA twice, once on mobile and once on my phone. Also clicked the recheck button multiple times. Maybe that integration is having issues?

The integration test is timing out at 300s on "When unmanaged Pod is created [It] Should create VulnerabilityReport". In my cluster, the modified trivy-operator creates a VulnerabilityReport for an unmanaged pod. On the line above that (460 in the test output, there is an error (below) which i think is the real cause of the failure:

failed to download policies: failed to download built-in policies: download error: oci download error: failed to fetch the layer: GET https://ghcr.io/v2/aquasecurity/trivy-checks/blobs/sha256:cba49b6781cfcdeb6b063283a711ce0ddb1f36d6e2a5db69ef7d2e3f13998149: TOOMANYREQUESTS: retry-after: 885.605µs, allowed: 44000/minute

[github-actions]

This PR is stale because it has been labeled with inactivity.