What you would like to accomplish: When using the default Google BuildPacks with the ‘gcloud functions deploy’ command, be able to define dependencies using Gradle Kotlin DSL ‘build.gradle.kts’ in addition to 'build.gradle'.
Use cases:
As of April 2023, Gradle's Kotlin DSL is the default for new builds [1]. Thus, a user following any basic Kotlin tutorial will likely run `gradle init` and end up with a build.gradle.kts file. If they later try to deploy their Kotlin code via Cloud Functions or Cloud Run (when using Google's buildpacks), they will encounter the error described in [2]. This presents a significant deterrent to using Kotlin in Cloud Functions / Cloud Run and is quite frustrating.
On the other hand, different Cloud services such as AWS Lambda does support Gradle's Kotlin syntax [3]. Additionally, the Android Studio docs overtly prefer the Kotlin syntax for Gradle [4]. For a team writing an Android app and wanting to use Kotlin for backend services via serverless, it is strongly preferred to have a consistent stack of Kotlin + build.gradle.kts.
Description
What you would like to accomplish: When using the default Google BuildPacks with the ‘gcloud functions deploy’ command, be able to define dependencies using Gradle Kotlin DSL ‘build.gradle.kts’ in addition to 'build.gradle'.
Use cases:
As of April 2023, Gradle's Kotlin DSL is the default for new builds [1]. Thus, a user following any basic Kotlin tutorial will likely run `gradle init` and end up with a build.gradle.kts file. If they later try to deploy their Kotlin code via Cloud Functions or Cloud Run (when using Google's buildpacks), they will encounter the error described in [2]. This presents a significant deterrent to using Kotlin in Cloud Functions / Cloud Run and is quite frustrating.
On the other hand, different Cloud services such as AWS Lambda does support Gradle's Kotlin syntax [3]. Additionally, the Android Studio docs overtly prefer the Kotlin syntax for Gradle [4]. For a team writing an Android app and wanting to use Kotlin for backend services via serverless, it is strongly preferred to have a consistent stack of Kotlin + build.gradle.kts.
References:
[1]
[2]
[3]
[4]