fix: Fix/8352 source map stack trace

[Cal-L]

Description

These changes fixes incorrect stack traces for errors on Sentry. Changes include:

• Bundle JS and upload files to Sentry using native scripts on iOS and gradle on Android
• In addition to uploading source maps, upload missing debug symbols for both iOS and Android
• Disable automatic Sentry file upload by default on both platforms
• Enable automatic Sentry file upload via environment variable SENTRY_DISABLE_AUTO_UPLOAD = false

Future improvements

• Replace Logger class with beforeSend and beforeBreadcrumbs in Sentry configuration
• Enable configuration for multiple environments in build script
• Documentation for Sentry implementation and usage
• Upload source maps and debug files to Bitrise for future reference (Deploy Source Map will fail for now on Bitrise but will not block)

Related issues

Fixes:

Manual testing steps

Note: Reference your own Sentry instance to see results. These tests focuses on having correct source maps as well as debug files uploaded to Sentry.

• By default, Sentry auto file upload is disabled for all but release builds (app store builds)
• To enable it for other build variants, you would need to set SENTRY_DISABLE_AUTO_UPLOAD env var to "false"
• If auto upload is enabled, both source maps and debug files should be uploaded to the Sentry instance that ties the release and dist to the associated release
• The end result, errors appearing on Sentry should contain the correct stack trace both for iOS and Android

Screenshots/Recordings

Before

Broken stack traces

After

Accurate stack traces

Caveat: Some errors may show with ses as the top level stack trace. We are working towards eliminating that layer so the error is more explicit. Drilling into the error still shows the correct trace so this is a non-blocker

Pre-merge author checklist

• I’ve followed MetaMask Coding Standards.
• I've clearly explained what problem this PR is solving and how it is solved.
• I've linked related issues
• I've included manual testing steps
• I've included screenshots/recordings if applicable
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.
• I’ve properly set the pull request status:
  • In case it's not yet "ready for review", I've set it to "draft".
  • In case it's "ready for review", I've changed it from "draft" to "non-draft".

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

E2E test started on Bitrise: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/445f3f6f-737f-424b-a5f4-908b6edae042
You can also kick off another Bitrise E2E smoke test by removing and re-applying the (Run Smoke E2E) label

[sethkfman]

LGTM

[sonarcloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud