-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Gutenberg] Add error boundary components and exception logging #20359
Changes from 6 commits
43526c5
32db175
fdaa982
9c4f788
f132e70
61dec5a
1a63c72
e87d6d8
b31495c
ce6908c
732fe40
bdf0b0f
6291d17
278fc9a
e63da63
6b0ad11
9408f29
b2ff729
08b5355
31beaac
82fe4b6
57cc01c
fe45679
17ba9b9
eadc097
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @wordpress-mobile/apps-infrastructure I'd appreciate it if someone could take a look at this approach for uploading the React Native's JavaScript source map file to Sentry. I'm mostly seeking validation of the approach, thoughts/feedback or better alternatives. Thank you very much for the help 🙇 ! To give some context on the approach: The source map is generated as part of the Gutenerg Mobile build process, the files are being passed as assets via the library (reference). Sentry uses the JavaScript bundle and the source map to symbolicate the stack trace and reference the exact code line that caused the exception (reference). The approach followed here consists in:
As a first approach, I tried to copy the bundle and source map files to a different folder during the asset merging step in the build process. However, I finally discarded this option because seemed unnecessary. Here you can see the changes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Approach looks good to me; thanks for documenting it all with comments 👍 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks @AliSoftware for taking a look and validating the approach, I appreciate it 🙇 . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following #20359 (comment) , we had to make an adjustment in order to avoid including the source map file (
index.android.bundle.map
) in the app. This file is only needed in the build process to upload it to Sentry and shouldn't be in the resulting APK.Originally, we tried using
exclude '**/*.bundle.map'
in this file (32db175) but for some reason, it was still adding the source map file. As a second approach, we are now copying the bundle and source map files to a separate folder and deleting the source map to avoid inclusion. The new folder will be used in theupload_gutenberg_sourcemaps
function when uploading the files to Sentry.@AliSoftware since you already took a look at the original approach (https://github.com/wordpress-mobile/WordPress-Android/pull/20359/files#r1510915719), I wonder if you could double-check that this approach is valid. Thanks for your help 🙇 !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I was focused on doing a CI deployment today, and only getting to this PR now, but I see it's already merged 🙂
I only skimmed the new code in
build.gradle
but your explanations above makes sense to me so I think the approach sounds good 👍There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No worries @AliSoftware. Yes, we finally decided to merge the PR (internal ref: p1710254914686709/1710180482.367029-slack-C06G8EGHE1H) to unblock other potential PRs, as the counterpart Gutenberg changes were already merged. In any case, if we identify improvements to be made to this approach, we'll be happy to apply them in a separate PR.
Great, thanks for taking a look and validating the approach 🙇 !