Skip to content

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

  1. Create a Gradle project with a build.gradle.kts file as build script.
  2. 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:

https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-maven/-/blob/fc091a93057f3d0d2aab97e0fdbf5df0dd74e7fa/plugin/plugin.go#L11

Edited by Florian Schäfer