codeql-action: [autobuild] org.gradle.execution.TaskSelectionException: Task 'testClasses' not found in root project 'xx' and its subprojects.
I have a brand new “Hello World” Android project created by Android Studio called HMMobile
.
I am trying to enable CodeQL (Java).
Here is the minimum reproduction repo: https://github.com/Hongbo-Miao/bug-codeql-java
In the CodeQL autobuild step, these lines worth mentioning:
[2022-12-04 00:02:09] [autobuild] > ./gradlew --no-daemon -S -Dorg.gradle.dependency.verification=off --init-script "/tmp/semmleTempDir/init.gradle" testClasses
[2022-12-04 00:02:09] [autobuild] Picked up JAVA_TOOL_OPTIONS: -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false
[2022-12-04 00:02:10] [autobuild] To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/7.4/userguide/gradle_daemon.html#sec:disabling_the_daemon.
[2022-12-04 00:02:11] [autobuild] Daemon will be stopped at the end of the build
[2022-12-04 00:02:18] [autobuild] FAILURE: Build failed with an exception.
[2022-12-04 00:02:18] [autobuild] * What went wrong:
[2022-12-04 00:02:18] [autobuild] Task 'testClasses' not found in root project 'HMMobile'.
[2022-12-04 00:02:18] [autobuild] * Try:
[2022-12-04 00:02:18] [autobuild] > Run gradlew tasks to get a list of available tasks.
[2022-12-04 00:02:18] [autobuild] > Run with --info or --debug option to get more log output.
[2022-12-04 00:02:18] [autobuild] > Run with --scan to get full insights.
[2022-12-04 00:02:18] [autobuild] * Exception is:
[2022-12-04 00:02:18] [autobuild] org.gradle.execution.TaskSelectionException: Task 'testClasses' not found in root project 'HMMobile'.
My code has no testClasses
inside. I am wondering why does CodeQL run the command with testClasses
?
./gradlew --no-daemon -S -Dorg.gradle.dependency.verification=off --init-script "/tmp/semmleTempDir/init.gradle" testClasses
(For default Android project created by Android Studio, the command to build is just ./gradlew build
. The command for unit test is ./gradlew test
)
Any guide to help fix would be appreciate. Thanks! 😃
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 22 (11 by maintainers)
The fix has been merged and will ship in the next CodeQL release after Christmas (expected mid-January). The cause was standard Android Gradle projects no longer explicitly referencing
com.android.tools.build:gradle
as of earlier this year, and consequently our autobuild heuristic to recognise such a project and avoid using the non-existenttestClasses
target no longer worked.I’ve identified the change we need to make; hope to have a fix PR today.
It does look for those plugins, but since your top-level file uses the alias
libs.plugins.android.application
you side-step the heuristic 😃There are more ambitious things we can do of course like tap into Gradle’s actual plugin resolution mechanism, but the number of relevant projects gets smaller and the effort larger as we tackle increasingly niche use cases.
The heuristic to spot an Android project is to look for a reference to the Android build tools in the root
build.gradle
file, which as of https://github.com/kevalpatel2106/pocket-ci/commit/a609ba05baacaf929440717ee1d65ef0bc24676a#diff-49a96e7eea8a94af862798a45174e6ac43eb4f8b4bd40759b5da63ba31ec3ef7 is no longer true.You will need instead to replace the
autobuild
step with a manual build command, such as./gradlew --no-daemon assemble
(or anything that builds the Java you want to analyse, and ideally spends as little time as possible doing extraneous things such as building other code, running tests, etc). Note the need for--no-daemon
because this can inhibit the build tracing that CodeQL uses to determine how your code fits together.@Hongbo-Miao @bcarterterp support for Android project detection when Kotlin build scripts are used has been merged; it should begin to roll out publicly in the next-but-one release, expected in roughly 2.5 weeks.
I’ve written a candidate fix – if it passes review it’ll get into the release after next, ETA ~24th January
Hah, well, when I wrote my original fix I said “huh, I notice we only seem to consider Groovy build scripts when checking if the user’s project looks like a Droid project, and we should consider Kotlin scripts too. There are a few other places where this applies too though; we should address the Groovy/Kotlin issue properly at a later date”
Well it looks like that later date came pretty quickly! I will take a look at this soon, though at this point I’m away for Christmas, so I’ll come back to the question on Jan 3rd.
@Hongbo-Miao you could try this nightly build: https://github.com/dsp-testing/codeql-cli-nightlies/releases/download/codeql-bundle-20221216/codeql-bundle-$os.tar.gz
Where $os is linux64, osx64 or win64.
You can also use that in a Code Scanning environment by passing that URL as the
tools
parameter to thecodeql/init
action.As always with a nightly build, there is absolutely no guarantee of quality as this is lightly tested at this stage – you should switch back to a regular release ASAP.