fix(subcmds/saas): remove timestamped directory in results-dir

[FutureHirai]

If this Pull Request is work in progress, Add a prefix of “[WIP]” in the title.

What did you implement:

• WHY

  • In the previous implementation, the results directory was not deleted when an upload failed. This could cause stale files from the failed run to be included in subsequent processes, potentially leading to inaccurate results.

• WHAT

  • Updated the logic to purge the results directory after each upload attempt, regardless of whether the upload succeeds or fails.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Before

./vuls -v
vuls v0.29.0 build-4e3ee6a

ls
2025-06-19T11-36-43+0900  2025-06-20T14-58-57+0900

./vuls saas
[Jun 20 15:06:29]  INFO [localhost] vuls-v0.29.0-build-4e3ee6a
[Jun 20 15:06:29]  INFO [localhost] Validating config...
[Jun 20 15:06:29]  INFO [localhost] Loaded: /XXX/XXXX/results/2025-06-20T14-58-57+0900
[Jun 20 15:06:35]  INFO [localhost] Uploading... NOTE12794
[Jun 20 15:06:39] ERROR [localhost] Failed to upload. err: Failed to upload data to vuls-results-tmp-prd/1/11118/fa797b8e-2447-ecd4-1e0d-e452ff2472f9.json, err:
    github.com/future-architect/vuls/saas.Writer.Write
        /home/runner/work/futurevuls-backend/futurevuls-backend/scanner-src/saas/saas.go:135
  - operation error S3: PutObject, https response error StatusCode: 0, RequestID: , HostID: , canceled, context deadline exceeded

ls
2025-06-19T11-36-43+0900  2025-06-20T14-58-57+0900

After

./vuls -v
vuls  build-20250619_115602_55cabca

ls
2025-06-19T11-36-43+0900  2025-06-20T14-58-57+0900

./vuls saas
[Jun 20 15:25:42]  INFO [localhost] vuls--build-20250619_115602_55cabca
[Jun 20 15:25:42]  INFO [localhost] Validating config...
[Jun 20 15:25:42]  INFO [localhost] Loaded: /XXX/XXXX/results/2025-06-20T14-58-57+0900
[Jun 20 15:25:47]  INFO [localhost] Uploading... NOTE12794
[Jun 20 15:25:52] ERROR [localhost] Failed to upload. err: Failed to upload data to vuls-results-tmp-prd/1/11118/fa797b8e-2447-ecd4-1e0d-e452ff2472f9.json, err:
    github.com/future-architect/vuls/saas.Writer.Write
        github.com/future-architect/vuls/saas/saas.go:138
  - operation error S3: PutObject, https response error StatusCode: 0, RequestID: , HostID: , canceled, context deadline exceeded

ls
2025-06-19T11-36-43+0900

Checklist:

You don't have to satisfy all of the following.

• Write tests
• Write documentation
• Check that there aren't other open pull requests for the same issue/feature
• Format your source code by make fmt
• Pass the test by make test
• Provide verification config / commands
• Enable "Allow edits from maintainers" for this PR
• Update the messages below

Is this ready for review?: YES

Reference

[shino]

Thank you very much for contributing!!

Before detailed review, please let me point two things:

1. for commit messages, we are using https://www.conventionalcommits.org/ja/v1.0.0/ . For example, fix(subcmds/saas): remove results-dir even when succeeded
2. in diff, tab characters and spaces are mixed. In Go lang, using only tag characters are standard, I guess.

Thanks again!

[Copilot]

Pull Request Overview

This PR ensures the results directory is purged after every upload attempt (success or failure) by moving the cleanup logic into a deferred function and removing the original post-success cleanup block.

• Moved os.RemoveAll(dir) into a defer so it always runs on exit
• Retained the debug flag check to skip removal in debug mode
• Removed the redundant cleanup block at the end of the function

Comments suppressed due to low confidence (2)

subcmds/saas.go:85

• [nitpick] The local variable dir is generic and could be renamed to resultsDir (or similar) to clarify its purpose in cleanup.

	defer func() {

subcmds/saas.go:85

• Consider adding unit tests that simulate both success and failure paths to verify the results directory is removed in all cases.

	defer func() {

[MaineK00n]

If an error occurs during the next scan and the timestamped directory is not created, there's a possibility that the previous one might be uploaded instead — is that acceptable?

[FutureHirai]

If an error occurs during the next scan and the timestamped directory is not created, there's a possibility that the previous one might be uploaded instead — is that acceptable?

We acknowledge that possibility. We have decided to cover this case with our operational workflow, so this is acceptable.

[shino]

Great Job!
Works as advertised!!! 🍻