How should I handle react-native iOS + Android with staging and production

1

I’m using react-native-sentry and am wondering how I should go about uploading sourcemaps for staging and production applications with iOS and Android platforms? Currently this is what I do:

react-native bundle \
  --dev false \
  --platform android \
  --entry-file index.js \
  --bundle-output android.main.bundle \
  --sourcemap-output android.main.bundle.map

react-native bundle \
  --dev false \
  --platform ios \
  --entry-file index.js \
  --bundle-output ios.main.bundle \
  --sourcemap-output ios.main.bundle.map

echo "Uploading react-native bundles to Sentry: "

node_modules/@sentry/cli/bin/sentry-cli releases \
    --org org \
    files com.example.app \
    upload-sourcemaps \
    --dist 1 \
    --strip-prefix ./ \
    --rewrite ./

The main thing I’m a bit confused about is regarding the release name. Since my CI builds 4 apps (2 for android + 2 for iOS = staging and production for each platform), how should I go about setting the RELEASE_NAME value for each of these platforms? Am I supposed to create 4 different releases? E.g:

 node_modules/@sentry/cli/bin/sentry-cli releases \
        --org org \
        files com.example.app.staging

 node_modules/@sentry/cli/bin/sentry-cli releases \
        --org org \
        files com.android.app.staging


 node_modules/@sentry/cli/bin/sentry-cli releases \
        --org org \
        files com.example.app

 node_modules/@sentry/cli/bin/sentry-cli releases \
        --org org \
        files com.android.app

With the above script, it would create 4 releases (1 per environment in each platform - ios and Android). Is this how I should be doing it?

2

Yes, unfortunately that’s the way to go right now. In order for Sentry to match your uploaded source map to your event, the release / dist of the event have to exactly match the release / dist of your release artifacts.

It doesn’t matter for dSYMs.

3

Is this still the official way to handle this? If I understand it correctly, there won’t be a reliable way to resolve issues as fixed in the “next” version