How it's different from gradle scans

[ritesh-singh]

Find the slowest parts of your build with the Gradle OpenTelemetry build plugin. This plugin instruments your build with OpenTelemetry traces and spans so you can visualize all tasks executed in your build, find where the build time is going, track build duration over time, etc. You'll get a trace for each build with a span for every task, so you can find and optimize the bottlenecks in your build.

Great work on plugin - 🙌

I wanted to initiate an discussion and understand, how the traces generated via this is different from gradle scans or develocity. I can get the same data via develocity api and generate a histogram/metrics and set-up some alert. Finding the slowest parts of the build is also easy, looking at scans time-line section. I was a bit excited for the distribution tracing across different machines on CI, when a build is split across different machines, generating a single trace, giving more information related to the runner.

I believe, this plugin hooks with the lifecycle of build, and generates tasks ~ spans in the DAG formed making a single trace.

[oleg-nenashev]

Well, there are some answers in the video: https://www.youtube.com/watch?v=qyYfcsu99aY . Gradle Build Scan is for Gradle/Maven/sbt or another build tool, while OpenTelemetry is rather designed to view your system and CI/CD Pipeline as whole (but with much lower insights and granularity). I will check whether I can document my opinion under the disclaimer

[ritesh-singh]

Thanks @oleg-nenashev I wonder, if this plugin also grabs information regarding the systems/runners, creating one single trace. For, example - Running a workflow on CI on different machines, and see the system as a whole - which task spent time on which runner and other relevant informations. I looked at the source code a bit and realised, it creates a span<>task, without gathering any additional information related to CI (I could be wrong, if i have missed something).

If this plugin offerings, is not taking care of CI telemetry as well, is it worth having it in system where develocity is well integrated, giving us the time spent of each task for the build or the critical path in the DAG, which can also help in evaluating, which tasks are slowing the build. Develocity, also offer certain api's which can be used and a metric can be created, exporting data finally to Grafana or any other visualisation tool.

I believe, one advantage here could be develocity scans timeline view doesn't show the task dependency in the form of parent-child relationship, as compared to the otel offering here.

I do understand, i think - the otel offerings <> Observablity. Just trying to understand it, in this use-case Develocity offering vs this plugin offering.

[craigatk]

Good question! Gradle build scans / Develocity are great products, and no need to adopt this plugin for the folks where those products are meeting their needs.

There are some differences in this plugin - for example:

• Ability to visualize the Gradle build as part of an overall trace of a CI build (shoutout to the folks who helped work on support for that) https://github.com/craigatk/opentelemetry-gradle-plugin?tab=readme-ov-file#remote-parent-trace
• Ability to integrate build duration & build other data into existing OpenTelemetry systems for a single place for visibility, alerting, etc.
• Ability to see the trace breakdown of individual test executions, see the effects of parallel test runs, etc.

Again, not saying this plugin is better than build scans / Develocity - more of another option for folks who are interested.

[ritesh-singh]

Thanks @craigatk

I definitely, missed - https://github.com/craigatk/opentelemetry-gradle-plugin?tab=readme-ov-file#remote-parent-trace

I was more thinking towards the capability of combining different trace outside of gradle, like open-telemetry/opentelemetry-collector-contrib#27460 (when that capability exists), to have more visibility on things which are not captured by gradle <> task lifecycle, like combining telemetry data of different runners or m/c with the gradle telemetry data generated via this plugin.

I definitely, need to explore and look more. Thanks, for the detailed response.