Closed realdadfish closed 5 years ago
And on a related note: For issue #702 (a pressing issue for everybody who is on AGP 3.4, which most people should be by now) exist two PRs, #705 and #706, none of which got a comment / approval by the maintainer, and therefor also weren't merged and released. Other than that there are multiple PRs open that date back until early 2018, late 2017.
It would be totally awesome if the community - which is apparently willing to help out - would get more attention.
I'm looking closely at those two PRs right now; I'm expecting to have a release out next week at the very latest.
We strongly appreciate all the contributions and everyone is more than welcome to open PRs but I believe think testing alpha builds with high volatility is feasible at this time. Once issues are raised by the community or through our own internal testing, we'll address them on release versions.
Setting up an automated test suite would be complex and cumbersome to maintain; open to suggestions into improving that discovery process however.
Leaving this open for discussion surrounding how we can do that.
I'm looking closely at those two PRs right now; I'm expecting to have a release out next week at the very latest.
Thank you!
We strongly appreciate all the contributions and everyone is more than welcome to open PRs but I believe think testing alpha builds with high volatility is feasible at this time.
Well, there is also quite a long beta time, where no breaking changes will occur, just bugs are fixed. Testing against those builds isn't an option on your side?
Setting up an automated test suite would be complex and cumbersome to maintain; open to suggestions into improving that discovery process however.
Wouldn't that be as easy as having an example project that comes with Sentry pre-configured having to execute ./gradlew assembleRelease
and then check if that run through well and the upload of the mapping file succeeded, and then execute this once per supported Gradle Plugin version?
Setting up an automated test suite would be complex and cumbersome to maintain; open to suggestions into improving that discovery process however.
Wouldn't that be as easy as having an example project that comes with Sentry pre-configured having to execute
./gradlew assembleRelease
and then check if that run through well and the upload of the mapping file succeeded, and then execute this once per supported Gradle Plugin version?
Ideally, there is Gradle's TestKit which can be used to automatically test mocked Gradle projects.
That would mean, though, having an Android SDK available at test time in order to be able to test gradle tasks correctly on either com.android.application
or com.android.library
test projects.
@ninniuz is correct that it would require an Android SDK, testing for both library and application projects.
Additionally, this would have to be applied across multiple versions of the SDK and the Android gradle plugin.
At this time that is a considerable amount of work and there are other priorities that come first. Keeping a closer watch on changes and testing manually, while also considering community contributions, seems like the way to go.
Additionally, this would have to be applied across multiple versions of the SDK and the Android gradle plugin.
At this time that is a considerable amount of work and there are other priorities that come first. Keeping a closer watch on changes and testing manually, while also considering community contributions, seems like the way to go.
It is important to note also the benefits in having the Android SDK integrated into your build process and test environment, apart from allowing you to automatically test your product, that is to ship the Android SDK library as an aar
.
That means potentially leveraging Android resources (not used at the moment, but who knows) and most notably consumer Proguard files without relying on the flaky way of adding Proguard rules through the Sentry Android plugin (that's something we already discussed a bit here as a community.
Hi @justacodefan
I'm looking closely at those two PRs right now; I'm expecting to have a release out next week at the very latest.
Seven days passed by, unfortunately without a new release, and Sentry's deobfuscation is still defunctional with AGP 3.4.0. What holds you off? :)
Best regards, Thomas.
So, twelve more days passed, still no release. This is getting ridiculous. Should anybody be better off forking this project and publishing his / her own binaries?
Last release was in March. We were getting faster releases back then. More than 2 in one month, maybe more. Once sentry-java had a critical bug encountered, releases stopped altogether. Not sure what's the strategy here? Not wanting to sound entitled, but community is ready to help and has created PRs regarding it. Sentry guys just have to create a new release. Which should have been made on urgent basis once this critical breakage was discovered. If this project is not a priority, then it should be mentioned as well.
Apologies the lack of attention this repo got during April/May. In the last month alone we've made 3 releases which included 15 bugfixes and features. Including for all the issues mentioned in this thread.
Sentry has hired an Android Developer to work with the community and help not only with bug fixes and small features but to move this project forward. He'll be joining in a couple of months.
I've raised an issue #744 to capture requirements for a refactor (likely a rewrite) of the Sentry Gradle Plugin. @ninniuz already contributed some draft in Kotlin which by be the seed for it but worst case this will be the first task of the new hire.
I'll close this issue, please feel free to discuss on #744 requirements for the gradle plugin.
In the past various issues popped up with the Sentry Android Gradle integration that could have easily been avoided if existing released Sentry versions would have been tested against alpha and beta versions of the Android Gradle Plugin.
The situation now is that Google releases a new version of their build tools and we basically have to cross fingers that Sentry still works or alternatively patch it ourselves or wait for an upstream patch to arrive.
How can this situation be improved? How can the compatibility of the Sentry Gradle Plugin be made more visible? Is there the commitment / manpower to test Sentry against alpha / beta versions even? Is there a way to setup an automated test suite that would test the integration in an example project and different AGP versions?