This sounds like a reasonable change to me. Shouldn't have any unintended side-effects as I highly doubt anyone is currently relying on the behaviour is specifically not being recursive.

Yeah, I hoped that would be the case!

Please allow me to share more use cases specifically for Java projects. With a multi-module Gradle project, static analysis tools like Checkstyle and Detekt can generate one or more reports per module. Therefore recursively walking through the directory is fairly common, at least for all gradle projects. I hope this issue can be addressed soon.

I did some quick search and it looks like the change is within this function upload-lib.js (https://github.com/github/codeql-action/blob/main/lib/upload-lib.js#L69). My Javascript skill is a bit rusty, but I can give it a try if this issue left unattended for a long time.

@chao2zhang Thanks for implementing this! Confirmed it works with my original clang scan-build output use case.

Did this make it work for you?

I'm always getting

  Error: Code Scanning could not process the submitted SARIF file:
  rejecting SARIF, as there are more runs than allowed (147 > 15)
  Error: Code Scanning could not process the submitted SARIF file:
  rejecting SARIF, as there are more runs than allowed (147 > 15)
      at Object.waitForProcessing (/home/runner/work/_actions/github/codeql-action/v2/lib/upload-lib.js:337:19)
      at async run (/home/runner/work/_actions/github/codeql-action/v2/lib/upload-sarif-action.js:56:13)

due to the many report-xxxxx.sarif files getting generated.

@Trass3r, please raise a new issue for this. You are seeing a different problem than was originally reported. Your workflow is producing too many sarif runs. You will need to upload them in batches of 15 or less and use a different (but consistent) category name for each upload.

More information about categories.

@Trass3r Yes, something changed and the server now rejects the SARIF output generated by Clang scan-build.

scan-build simply produces 1 sarif file per source file.
Even though most are empty 15 is still a pretty low limit.
It can be mitigated a bit via

npx -y @microsoft/sarif-multitool merge csa/*/*.sarif

But I can't say yet whether that really fixes the problem.