Add analytics for the gradle plugin

[romtsn]

We could utilise sentry-java for that, so we can get:

• Automatic error monitoring
• Transactions for task execution
• Transactions for tracing instrumentation
• Check adoption via release health feature (?) (what will be a "user" in our case? a project? an org? a developer?)
• Send sentry log files and the failed artifacts as attachments

Some caveats:

• It should be an opt-in feature, because it potentially will slow down the builds.

[cortinico]

This was partially surfaced in the past here: https://github.com/getsentry/sentry-android-gradle-plugin/pull/126

• It should be an opt-in feature, because it potentially will slow down the builds.

Agree. I'm actually more concerned of the potential security/privacy risks.

[romtsn]

Yea, I think we need to do our best here to make it anonymous/pseudononymous.

[marandaneto]

The SDK does not collect any PII by default tho, I'm not super concerned about that.

[philipphofmann]

Before doing this, we need to make sure that this is compliant with our Sentry policies; ask Jan and/or Armin.

[marandaneto]

@romtsn will talk to folks and figure out if this is something we'd like to do.

[romtsn]

javascript folks already do this for their bundler plugins https://github.com/getsentry/sentry-javascript-bundler-plugins, so most likely there's no problem to do this on our side as well. But we should double-check with Armin/legal as they had concerns in the past

[markushi]

Just talked with Steven about this topic, pretty much the same has been done for https://github.com/getsentry/sentry-javascript-bundler-plugins already, and it ran through legal as well.

make it opt out and PII stripped and good to go IMO

Luca/Lukas should have some more technical details about this topic.

[smeubank]

@adinauer fyi

[adinauer]

Just gave the JS PR and code as well as this PR that moved some code a glance - here's the summary:

• Sending analytics / telemetry is an opt-out feature (option is called telemetry)
• Uses our performance product (tracesSampleRate = 1.0 if telemetry enabled)
• Captures errors (sampleRate = 1.0 if telemetry enabled)
  • Captures minimal error (status, message and stack only)
• Uses lots of tags
  • Should we do that differently considering we no longer want lots of tags?
• On top of checking whether telemetry is enabled, also checks Sentry URL and disables telemetry / analytics if not running against SAAS. Also runs sentry-cli info to figure out server url (Sentry Server:) from other CLI config mechanisms.
• Logs a message, telemetry is enabled and how to disable it
• Sets org id as user

Not quite sure whether the JS plugin only captures errors, breadcrumbs and performance data for Sentry tasks or applies to generic build system tasks (unrelated to Sentry) as well. Maybe @lforst or @Lms24 can take a quick look at above list and answer this question 🙏 .

Another request was to use sessions so we can get usage numbers not affected by dynamic sampling (Talk to @smeubank for more details here).

[romtsn]

Sessions don't work on the pure Java SDK though, do they?

Also, bear in mind that we'll most likely have to use BuildService for Sentry due to Gradle's build lifecycle.

[adinauer]

I don't think we need aggregate sessions for this, so the kind of sessions used by Android should work here unless I misunderstood what @smeubank wants to do.

[lforst]

Thoughts:

• Don't capture the stack trace. It might contain PII via paths.
• Don't capture error messages. They might contain PII. Use manual very bare errors instead.
• We don't want our SDKs to set tags themselves. In the plugins this is fine.
• If you're somehow using Sentry CLI you can use an environment variable to send along trace ID to have distributed tracing.
• Telemetry should only be enabled by default if people are on SaaS.
• Sessions are the most reliable way of tracking invocations because they will not be affected by dynamic sampling as opposed to transactions.

[Lms24]

One more thing RE tags: It's easy to make discover queries/dashboard widgets with tags. We do this quite extensively with our source maps wizard. for example, to analyze user decisions taken along the way.

[adinauer]

@lforst

If you're somehow using Sentry CLI you can use an environment variable to send along trace ID to have distributed tracing.

Do you know which env var that is? I'm unable to find it.

[lforst]

@adinauer Sorry, I think what I meant was you can use the CLI's --header option to pass along a sentry-trace and baggage header to the Sentry backend. I don't think the CLI has telemetry yet.