Support build scripts using Gradle's Kotlin DSL for Dependency Scanning (Gradle)
Previous discussion: #9742 (comment 289712698)
Summary
Dependency scanning in GitLab CI currently supports Gradle build scripts written in Gradle's Groovy DSL (filename of the build script is build.gradle
).
For a while now Gradle allows its users to write the build scripts in their Kotlin DSL (filename of the build script is build.gradle.kts
).
If a project uses the Kotlin DSL, dependency scanning will currently not recognize the project as using Gradle and therefore will not execute.
Since it has come up in previous discussion, this is not about compiling Kotlin code (*.kt
files), but about writing a Gradle build script using Gradle's Kotlin DSL. The Kotlin DSL is an officially supported alternative way of writing Gradle build scripts. Since Gradle 5.0 it is stable (current version is 6.2.2, a pre-release of Kotlin DSL was introduced in some 4.x version) and most (if not by now all) samples in the documentation show both the Groovy DSL and Kotlin DSL for examples. It's supported out of the box by Gradle, you just use build.gradle.kts
with Kotlin DSL or build.gradle
with Groovy DSL and Gradle picks it up. Especially for Android projects the Kotlin DSL would be the obvious choice, since Kotlin is used to write more and more Android apps, also Android Studio and IntelliJ idea support the Kotlin DSL better than the Groovy DSL by offering better autocompletion and refactoring.
One thing you might want to keep in mind is that you probably want to use the Gradle Wrapper (filename gradlew
) for Gradle projects if present in the project. I saw in #33639 (closed) that at least for license management GitLab CI always uses Gradle 4.10, for dependency scanning I haven't checked. But since especially the Kotlin DSL was not yet final in version 4.10, projects with a Gradle Wrapper of a newer version might fail because of an older Gradle version in use.
Steps to reproduce
- Create a Gradle project with a
build.gradle.kts
file as build script. - Try to enable Dependency scanning in GitLab CI.
Example Project
Project: https://gitlab.com/JOSM/plugin/Mapillary/-/tree/d53d4367d2909d01870b431b301e61a42b3e794f
Failing CI job: https://gitlab.com/JOSM/plugin/Mapillary/-/jobs/440314860
What is the current bug behavior?
Dependency scanning fails with No compatible analyzer can be found
What is the expected correct behavior?
Dependencies are actually scanned.
Relevant logs and/or screenshots
Excerpt from https://gitlab.com/JOSM/plugin/Mapillary/-/jobs/440314860#L170
Digest: sha256:29914ecaaa6a0387b7d0a679a6f5ee1cbe28211c3279cbdfaef6e1ace4b41516
Status: Downloaded newer image for registry.gitlab.com/gitlab-org/security-products/dependency-scanning:12-7-stable
2020/02/17 18:30:20 Copy project directory to containers
2020/02/17 18:30:20 [bundler-audit] Detect project using plugin
2020/02/17 18:30:20 [bundler-audit] Project not compatible
2020/02/17 18:30:20 [retire.js] Detect project using plugin
2020/02/17 18:30:20 [retire.js] Project not compatible
2020/02/17 18:30:20 [gemnasium] Detect project using plugin
2020/02/17 18:30:20 [gemnasium] Project not compatible
2020/02/17 18:30:20 [gemnasium-maven] Detect project using plugin
2020/02/17 18:30:20 [gemnasium-maven] Project not compatible
2020/02/17 18:30:20 [gemnasium-python] Detect project using plugin
2020/02/17 18:30:20 [gemnasium-python] Project not compatible
No compatible analyzer can be found
Output of checks
This bug happens on GitLab.com
Possible fixes
In the following line, dependency scanning only looks for a build.gradle
file and rejects build.gradle.kts
files: