Nicola Corti

> when doing this, we can remove the `Upload Test Results` step from `pre-merge.yaml` The reason behind that step is to be able to easily see what was the failure...

That's a valid report. The fix should be as easy as updating those two annotations to `@InputDirectory`: https://github.com/getsentry/sentry-android-gradle-plugin/blob/106289f3f3fd0e33d603f1ed33983a498ff10612/plugin-build/src/main/kotlin/io/sentry/android/gradle/tasks/SentryUploadNativeSymbolsTask.kt#L22 https://github.com/getsentry/sentry-android-gradle-plugin/blob/106289f3f3fd0e33d603f1ed33983a498ff10612/plugin-build/src/main/kotlin/io/sentry/android/gradle/tasks/SentryUploadProguardMappingsTask.kt#L28

> variant API is now stable: [developer.android.com/studio/releases/gradle-plugin#7-0-0](https://developer.android.com/studio/releases/gradle-plugin#7-0-0) > [https://github.com/android/gradle-recipes/tree/agp-7.0/Kotlin](https://github.com/android/gradle-recipes/tree/agp-7.0/Kotlin?rgh-link-date=2021-07-29T08%3A52%3A49Z) Awesome 🎉 I believe we want to try to land this https://github.com/getsentry/sentry-android-gradle-plugin/pull/106 first right?

Just dropping my thoughts here: shouldn't the list of dependencies be uploaded at build time instead? Imho the list of deps should be uploaded alongside the proguard mapping and matched/displayed...

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...

> Bumping to Java 11 lead me to this issue [youtrack.jetbrains.com/issue/KT-48745](https://youtrack.jetbrains.com/issue/KT-48745) That is just a warning though, no?

> what's the reason for that actually? No inputs? Could we depend on the r8 task perhaps, or is it gonna be too late already? IIRC it was a requirement...

> Or can we depend on the outputs of R8 task? Yes but I'd like this task to be minifier-agnostic (i.e. I don't want to assume that R8 is actually...

Just a small heads up here. This Gradle plugin is pulling in several dependencies that are clashing with the one needed by Android Gradle plugin (see #21). Specifically is pulling...

Thanks for this PR > Also the approach taken is as mentioned in #116 I'd like to challenge the approach a bit as this looks like a bit of an...