Use build-mode: none for Monorepo

[mat-sylvia-mark43]

I am attempting to use the build-mode: none beta feature in a project monorepo (private repo) that is primarily Java but also has some TS/JS. Error below shows that this failed, but it's not clear at all why the Java couldn't be scanned:

Encountered a fatal error while running "/opt/actions-runner/_work/_tool/CodeQL/2.17.3/x64/codeql/codeql database finalize --finalize-dataset --threads=8 --ram=29537 /opt/actions-runner/_work/_temp/codeql_databases/java". Exit code was 32 and last log line was: CodeQL detected code written in Java/Kotlin but could not process any of it using the 'none' build mode.

So my question is: is there a way to get this to work? Perhaps with some include paths or something like that or is this a strict situation were Java + TS, JS, etc. is detected the build-mode: none option is not possible, hard stop? Similar discussions on this topic didn't yield any assistance.

[jketema]

Hi @mat-sylvia-mark43,

Would to be possible for you to share the logs (possibly partially anonymised, because they may contain sensitive information)? Without those it's difficult to tell what is going on.

If the above if not possible here, running CodeQL on a private repo likely means you're a paying customer, in which case you can also file a support ticket, which offers more privacy. See here: https://docs.github.com/en/support/contacting-github-support/creating-a-support-ticket

[aibaars]

@mat-sylvia-mark43 If you open a support ticket, please ask them to escalate with medium priority to the CodeQL team and reference this discussion.

Also please re-run the failed workflow with "debug logging" enabled, and include a copy of the workflow file, the actions logs, and the codeql debug artifacts that are attached to the summary of the workflow run. Note that the debug artifact contains sensitive information including the analysed source code. If you are uncomfortable sharing source code with the support team, please strip that data from the debug artifact before sharing.

[mat-sylvia-mark43]

Thanks @aibaars I am using self-hosted runners but they are large (8CPU/32GB/SSD). I did open a ticket (#2809181) so I'll have them escalate. I am NOT using include/exclude paths in this workflow config.

[mat-sylvia-mark43]

@aibaars follow up: I asked support to escalate per your guidance.

After reviewing the detailed logs myself I saw issues with a JDK, so I used the setup-java GHA to make sure that was set, and saw:

No specific JDK inferred from the project being analysed; using the java on the PATH in a current run HOWEVER....success was had so I believe this to be the fix. I missed this requirement in this doc: https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages#building-java--and-kotlin

Do you know why the init step still downloads all maven dependencies though? I'm wondering if this can be avoided to speed up the process as using no-build in this situation was only ~2mins after than when conducting a build & scan.

[aibaars]

I see the problem now. You're right that installing a JDK on your runner fixes the issue. CodeQL looks for the best suitable JDK version it can find, if no good match is found it falls back on whatever java is installed on the PATH, and if even that doesn't exist it should fall back on its own internal minimal JDK. Unfortunately, there was a mistake in the path of the internal JDK so things failed. Thanks for reporting!

[aibaars]

About installing dependencies. The buildmode:none for Java roughly works by scanning the source folder for *.java files and simulating a compilation run with those files. The simulated compilation run still needs the JAR files of all dependencies on the classpath. To figure out what the dependencies are it may run a gradle or maven plugin to list the required JARs, download them and put them on the classpath. In addition the simulated compiler will try to guess a suitable dependency to download from Maven Central in case a symbol from a package could not be resolved. It does its best to have as few unresolved symbols as possible to maximise the analysis quality. However, if after all its efforts a symbol cannot be resolved, it simply carries on, writing a warning to the log but not failing like a real compiler would.

[mat-sylvia-mark43]

@aibaars Really appreciate the extra detail there, thank you!!