Fixed TestAssetsFromDir unit test failure on Windows

[bobsira]

• Added a t.Cleanup hook that iterates over every CopyableFile returned by assetsFromDir and calls Close(). This releases the open file descriptors created by assets.NewFileAsset.
• This directly fixes the Windows test failure where RemoveAll couldn’t delete temp files because they were still open.
• Switched some non-fatal t.Errorf + return cases to t.Fatalf for earlier, clearer abort when setup fails (creating test files or gathering assets).

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: bobsira
Once this PR has been reviewed and has the lgtm label, please assign prezha for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @bobsira. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[minikube-bot]

Can one of the admins verify this patch?

[bobsira]

@medyagh @nirs can I get some eyes on this PR.

[nirs]

Too much changes, It think only one is needed to fix the windows build. Can we focus only on fixing the windows build and defer other changes for later?

[nirs]

This must be called before calling assetsFromDir().

[bobsira]

Please clarify more on this because the current placement looks fine to me since:

• assetsFromDir opens the files (via assets.NewFileAsset) and returns []assets.CopyableFile. We don’t have anything to close until you have that slice.
• We register t.Cleanup immediately after obtaining actualFiles. That’s the earliest possible point we can close them reliably.
• t.Cleanup runs after the subtest finishes (even if it fails), so descriptors are released in all cases.
• Moving the cleanup registration “before” the call would be impossible (the slice doesn’t exist yet) unless we refactored assetsFromDir to accept a callback, which is unnecessary for a test.

[nirs]

So if assetsFromDir fails, we don't have anything to cleanup? Can return incomplete results and fail?

If it either return slice or fail without opening anything we are fine with current code. If it can open some files and fail, we can either clean up in assetsFromDir, or here by registring the cleanup before we call:

var actualFiles []Xxx
t.Cleanup(...)
actualFiles = ...

But it will probably better to cleanup in assetsFromDir() or a test helper using it. Test helpers should get a t *testing.T argument and handle cleanup and test failures internally so the test code is simpler.

[bobsira]

I introduced a collectAssets(t, root, dest, flatten) test helper that:

• Calls assetsFromDir once and immediately registers a t.Cleanup to close any FileAsset descriptors it opened (including partial slices if the walk fails).
• Keeps error handling + cleanup localized so each subtest only sets up files and validates the mapping. This addresses the earlier concern about calling cleanup “early enough” without modifying production code. Moving cleanup into assetsFromDir would change its resource lifecycle semantics for other callers, so keeping it in a test helper preserves current behavior while preventing leaks on Windows. Let me know if you’d prefer an additional error-path test; happy to add one if we can deterministically trigger a walk failure.