Change:
// Print the output to stdout and a logfile which will be returned // as part of the results tarball. logFilePath := filepath.Join(resultsDir, logFileName) <ins> // ensure the resultsDir actually exists if _, err := os.Stat(resultsDir); os.IsNotExist(err) { log.Printf("The resultsDir %v does not exist, will create it", resultsDir) if mkdirErr := os.Mkdir(resultsDir, 0755); mkdirErr != nil { return fmt.Errorf("failed to create log directory %v: %w", resultsDir, mkdirErr) } } </ins> logFile, err := os.Create(logFilePath) if err != nil { return fmt.Errorf("failed to create log file %v: %w", logFilePath, err)

Discussion:
When I try to run conformance test with a docker command, it failed with this error output. While and are still working. I take a look at the code (on branch release-1.22) Seems we should create the directory for the log file before I fixed it with this code. The conformance test should work with v1.22.x docker run -it No response <details</details<detailsLocal develop env </details<details</details<details</details<details</details<details</details
/sig testing
Do you want to create a PR for this?
/area conformance The folder is specified by an environment variable , I don't know if allowing to create folders is a good idea instead of setting the correct variable you are more familiar than me with this image, any ideas?
Normally this image is invoked with some parameters specified (e.g. it will need cluster access ...), is there a use case for running it like this? I'm curious what changed, I don't recall any related changes in 1.22 cc
21 or earlier versions, Conformance test use the as the entrypoint, but now 1.22 change to the gorunner(first used as default entrypoint). The parameter RESULTSDIR has default value, we used to leave is as default value, and it works with 1.21 or earlier versions.
/triage accepted Within the project we primarily run binary directly, this image is primarily for use-cases like sonobuoy and has been developed by that team. I'm personally way over capacity to work on this but maybe one of the sonobuoy folks can. cc
hmm yeah I don't think running container ~locally~ without saving the results externally was in the use case that we considered when we did , because we were banking on to be consistent with the mounted volume (therefore the folder must exist) like the following: I think the default value is working as expected here, because the error message has the right path (i.e. ) just that maybe the old Dockerfile has pre-initialized, which is a another option to fix this without adding Go code. I don't feel too strongly about either approaches of fixing this, though I think the non-fixing approach will be to run the image with if you'd like to unblock yourself for now.

Yea you normally wouldn't run the conformance image via just ; that RESULTS_DIR it uses is referencing a mounted volume which I guess is the issue. I don't mind at all if the code is updated to do a mkdirall call in case the folder doesnt exist.
Okay, let me create a PR to do the mkdir if the foler is not exists
did you create a PR yet?
yes, please help to review the following PR
This actually just came up and helped me find a bug elsewhere. I was able to just mount the pwd as the results directory (which is an alternative to fixing this at all). In my case, I actually didn't expect to need that at all, so I realized the entrypoint for the conformance image had changed and I had to invoke the image with the option before specifying the image name.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
closing as WONTFIX