I’m trying to update a Kotlin multiplatform projec...

# gradle

[Carter]

I’m trying to update a Kotlin multiplatform project to Kotlin 1.7.21, and I’m hitting a failure that I’m including in a thread.

The project is using Gradle 7.6. I use kts for my build scripts, and I have some build conventions set up. Because the build conventions are for the Kotlin multiplatform Gradle plugin, I do include the Kotlin 1.7.21 plugin in the build convention dependencies. The last thing I have is dependency locking enabled.

The build failure happens when I trigger a build on GitHub Actions, but I can’t trigger the same failure locally on my Mac.

I realize that’s a lot of variables, but I suspect the combination of dependency locking and including Kotlin 1.7.21 for the build convention ends up causing the failure. If I disable dependency locking, the issue goes away.

I’m glad to file a YouTrack issue, but I’m having trouble narrowing this down further. Thoughts on anything else I can try?

[Carter]

* What went wrong:
558
> Task :assertion-lib:compileCommonMainKotlinMetadata
559
Execution failed for task ':assertion-lib:compileKotlinJvm'.
560
> Could not resolve all files for configuration ':assertion-lib:detachedConfiguration1'.
561
   > Failed to transform kotlin-stdlib-jdk8-1.7.21.jar to match attributes {artifactType=classpath-entry-snapshot, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}.
562
      > Execution failed for ClasspathEntrySnapshotTransform: /home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk8/1.7.21/5407c3593c58860cec5ee3f66c468396b42f4c2b/kotlin-stdlib-jdk8-1.7.21.jar.
563
         > 'byte[] org.jetbrains.kotlin.incremental.storage.ExternalizersKt.toByteArray(org.jetbrains.kotlin.com.intellij.util.io.DataExternalizer, java.lang.Object)'
564
   > Failed to transform kotlin-stdlib-jdk7-1.7.21.jar to match attributes {artifactType=classpath-entry-snapshot, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}.
565
      > Execution failed for ClasspathEntrySnapshotTransform: /home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jdk7/1.7.21/a0ba09615c2213d580315e234b3febfea25b757e/kotlin-stdlib-jdk7-1.7.21.jar.
566
         > 'byte[] org.jetbrains.kotlin.incremental.storage.ExternalizersKt.toByteArray(org.jetbrains.kotlin.com.intellij.util.io.DataExternalizer, java.lang.Object)'
567
   > Failed to transform kotlin-stdlib-1.7.21.jar to match attributes {artifactType=classpath-entry-snapshot, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}.
568
      > Execution failed for ClasspathEntrySnapshotTransform: /home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.7.21/1a2eaf898a0dda83037034b10a42053cf8a7caf8/kotlin-stdlib-1.7.21.jar.
569
         > 'byte[] org.jetbrains.kotlin.incremental.storage.ExternalizersKt.toByteArray(org.jetbrains.kotlin.com.intellij.util.io.DataExternalizer, java.lang.Object)'
570
   > Failed to transform annotations-13.0.jar to match attributes {artifactType=classpath-entry-snapshot, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}.
571
      > Execution failed for ClasspathEntrySnapshotTransform: /home/runner/.gradle/caches/modules-2/files-2.1/org.jetbrains/annotations/13.0/919f0dfe192fb4e063e7dacadee7f8bb9a2672a9/annotations-13.0.jar.
572
         > 'void org.jetbrains.kotlin.incremental.storage.ExternalizersKt.saveToFile(org.jetbrains.kotlin.com.intellij.util.io.DataExternalizer, java.io.File, java.lang.Object)'

[tapchicoma]

Looks like more related to new Incremental compilation from the log

[tapchicoma]

Could you provide a build scan with error?

[Chris Lee]

When building Gradle consumables (plugins/tasks) with ‘Kotlin-dsl’, Gradle uses an embedded Kotlin. Do not add Kotlin dependencies on plugins as this causes conflicts.

[Josh Eldridge]

But why would this cause issues on github actions vs locally? I'm following this thread because I too have had build failures on github actions similar to this but locally it builds fine

[Chris Lee]

perhaps there are CI actions that aren’t run locally, or the local dependency cache is different. For the latter, running with “--refresh-dependencies” or removing ~/.gradle/caches would be a good test.

[Josh Eldridge]

Good idea 👍

[Carter]

I’m struggling to get a build scan working. I’m assuming you need it from the CI server where the build is failing, rather than locally from my machine which is working just fine.

To my settings.gradle.kts, I added

plugins {
    id("com.gradle.enterprise") version("3.11.4")
}

gradleEnterprise {
    buildScan {
        termsOfServiceUrl = "<https://gradle.com/terms-of-service>"
        termsOfServiceAgree = "yes"
    }
}

And then I re-ran my Gradle task locally with --write-locks

When I run it again without --write-locks then I end up with an error:

Could not resolve all files for configuration 'classpath'.
169
> Did not resolve 'com.gradle:gradle-enterprise-gradle-plugin:3.11.4' which is part of the dependency lock state
170
> Did not resolve 'com.gradle.enterprise:com.gradle.enterprise.gradle.plugin:3.11.4' which is part of the dependency lock state

Having dependency locking turned on is part of what triggers this issue.

Is there another way to disable the TOS agreement on CI without applying the Gradle enterprise plugin?

[Chris Lee]

not sure how much a build scan will help given that resolution is failing. Have you been able to reproduce locally, using same JVM version, Gradle version, and with forcing dependency resolution (--refresh-dependencies, rm -rf ~/.gradle/caches)?

I do include the Kotlin 1.7.21 plugin in the build convention dependencies

If the Kotlin plugin is mixed with kotlin-dsl that can cause problems that manifest this way.

[Carter]

Yes I’ve done all those things and it doesn’t reproduce locally.

[Chris Lee]

is there a full stacktrace (--stacktrace)?

[Carter]

That I can generate but it requires triggering another CI job

[Chris Lee]

would be helpful. Execution failed for ClasspathEntrySnapshotTransform is interesting, but there’s nothing in the output that says why it failed. Hoping the stack trace will enlighten us.

[Chris Lee]

The contents of gradle.properties would be helpful (from the project directory and your home directory). If CI has additional properties that would be interesting. And the command use to run Gradle in CI, including any properties that are set (-Pxxx=yyy).

[tapchicoma]

probably try Kotlin 1.8.0-Beta - there were some changes around dependencies and their earlier resolution

[Carter]

Untitled.txt

[Carter]

I’ll try the 1.8.0-Beta next.

In the meantime, that’s the stacktrace on the CI machine in the snippet above.

[Carter]

Kotlin 1.8 beta builds on CI without error, although I had to strip out my module using the kotlinx benchmark library as there seems to be an incompatibility there.