github
1 files were completely excluded from scanning due to a fundamental problem that is known to cause problems scanning other files.
I created a new test repository for setting up various github actions. The repository itself does not have real important code other than to demonstrate various things like a functioning build-pipeline even in case of module usage and such. The task I was given is to create releases to Maven Central on manual tags rather than to rely on the default release cycle.
While investigating into CodeQL action, I noticed that a warning is popping up during the Perform CodeQL Analysis step of the pipeline.
The exact message here reads as:
1 broken classes filtered out (1 result)
* 1 files were completely excluded from scanning due to a fundamental problem that is known to cause problems scanning other files. Presently these are `module` declarations in a file not named `module-info.java`.
The warning is not really helpful at all as I can't really determine which file it is referring to even though this repo only has a handful of files. Not sure how much of an effort it would be to at least list the files that CodeQL is complaining about would be a sane thing IMO. The reported problem seems also a bit strange as there is a module-info.java file that declares a Java module. Which other file should there be that "declares" a module but is not within a module-info-java file?
The cause is that you're running a build (note the mvn compile command) after codeql-init in the context of a build-mode: none extraction. As of the forthcoming CodeQL release, the build would be ignored -- for now, you can either change build-mode to one that traces the build, or else remove the build step from your workflow.
Thank you for the info. I just replaced the autobuild step that was initially suggested, which was not working for me, with the build step I am using. Is the build step actually needed by CodeQL or does it only analyze the source code? I mean, is adding a build on top of it adding any further value?
It depends on the build-mode option. If set to none, we do not depend on a build process, though we may try to interrogate a build tool for dependency info. If set to autobuild or manual then we operate by tracing a build process, using a guessed build command like mvn package or relying on you to run a build respectively.
The particular oddity seen here results from the unexpected combination of build-mode: none, but running a manual build anyhow.