Plugin causes issues with configuration cache

[mikaoura]

(This is documented but would be nice to see fixed)

When adding the plugin to a project using gradle configuration cache I see the following errors:

Configuration cache problems found in this build.

2 problems were found storing the configuration cache.

• Plugin 'com.atkinsondev.opentelemetry-build': registration of listener on 'Gradle.addBuildListener' is unsupported
  See https://docs.gradle.org/8.4/userguide/configuration_cache.html#config_cache:requirements:build_listeners
• Plugin 'com.atkinsondev.opentelemetry-build': registration of listener on 'Gradle.addListener' is unsupported
  See https://docs.gradle.org/8.4/userguide/configuration_cache.html#config_cache:requirements:build_listeners

This can be worked around by putting the following in gradle.properties:

org.gradle.configuration-cache.problems=warn
org.gradle.configuration-cache.max-problems=2

However, with those telemetry is only produced when there is a configuration cache miss.

[craigatk]

Yeah unfortunately that's one of the current limitations of the plugin https://github.com/craigatk/opentelemetry-gradle-plugin?tab=readme-ov-file#limitations

Gradle unfortunately doesn't have a drop-in replacement for the before/after listeners that works with the configuration cache. I'm exploring options to work with the Gradle build services instead to be compatible with the configuration cache, but it'll take a bit as it'll be a complete re-architecture of the plugin.

[craigatk]

I've updated the plugin at v2.2.0 to add experimental support for using the plugin with the configuration cache.

Docs are here, please give it a try and let me know how it works for you :) https://github.com/craigatk/opentelemetry-gradle-plugin?tab=readme-ov-file#gradle-configuration-cache

[mikaoura]

Thanks! We'll take a look.

[mikaoura]

I'm seeing an error with both 2.2.0 and 3.0.0 running ./gradlew help as well as ./gradlew <assemble something>:

* Exception is:
org.gradle.api.internal.provider.MissingValueException: Cannot query the value of this property because it has no value available.
        at org.gradle.api.internal.provider.AbstractMinimalProvider.calculateOwnPresentValue(AbstractMinimalProvider.java:82)
        at org.gradle.api.internal.provider.AbstractMinimalProvider.get(AbstractMinimalProvider.java:100)
        at com.atkinsondev.opentelemetry.build.service.TaskEventsService.onFinish(TaskEventsService.kt:55)
        at org.gradle.internal.build.event.DefaultBuildEventsListenerRegistry$ForwardingBuildEventConsumer.handle(DefaultBuildEventsListenerRegistry.java:261)
        at org.gradle.internal.build.event.DefaultBuildEventsListenerRegistry$ForwardingBuildEventConsumer.handle(DefaultBuildEventsListenerRegistry.java:238)
        at org.gradle.internal.build.event.DefaultBuildEventsListenerRegistry$AbstractListener.run(DefaultBuildEventsListenerRegistry.java:180)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)

This is on gradle 8.7

Running without configuration cache works. Explicitly setting supportConfigCache = true doesn't make a difference.

[craigatk]

Thanks for the heads up about that error! I'll investigate 👀

[craigatk]

I released a new version 3.0.1 that should hopefully fix that issue. Please give it a try and let me know if it works for you :)

[mikaoura]

Right, the error is gone. However, the top-level span length is wrong when using configuration cache: it seems to count time from the time the configuration cache was created:

A colleague also pointed out, that with previous versions no telemetry is produced when configuration cache is used.

(Could also be that some id is reused and the telemetry gets interpreted as having a long span)

[craigatk]

Thanks for trying it out! I'll look into what's going on with the duration of the top-level span 👀

[craigatk]

I released a new version of the plugin 3.1.1 that will hopefully fix that start-time problem with the root span. Please give it a try and let me know if it works for you :)

[mikaoura]

Thanks a lot!

Looks promising after testing a couple of cases. Will close the issue once we have a few days of data (prob. after the holidays).

[craigatk]

Sounds good, thanks for testing it out!