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

CodeQL full error log

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)

Most upvoted comments

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-existent testClasses target no longer worked.

smowton on Dec 12, 2022

I’ve identified the change we need to make; hope to have a fix PR today.

smowton on Dec 6, 2022

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.

smowton on Feb 27, 2023

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.

smowton on Feb 27, 2023

@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.

smowton on Jan 23, 2023

I’ve written a candidate fix – if it passes review it’ll get into the release after next, ETA ~24th January

smowton on Jan 6, 2023

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.

smowton on Dec 16, 2022

@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 the codeql/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.

smowton on Dec 16, 2022