Sentry-cli: For sentry-cli react-native appcenter, won't the Sentry release names conflict? (Staging vs. Production)

[m-pol]

I'm using this code to generate React Native CodePush releases:

sentry-cli --auth-token [my auth token] react-native appcenter [my AppCenter iOS project] ios ./build/ios/CodePush --deployment Staging --bundle-id [my bundle id]

sentry-cli --auth-token [my auth token] react-native appcenter [my AppCenter Android project] ios ./build/android/CodePush --deployment Staging --bundle-id [my bundle id]

sentry-cli --auth-token [my auth token] react-native appcenter [my AppCenter iOS project] ios ./build/ios/CodePush --deployment Production --bundle-id [my bundle id]

sentry-cli --auth-token [my auth token] react-native appcenter [my AppCenter Android project] ios ./build/android/CodePush --deployment Production --bundle-id [my bundle id]

The releases generated by the sentry-cli are named like so:

[my bundle id]-codepush:v123

etc., where vXXX is the CodePush release.

However, my CodePush Android/iOS projects are on different version numbers, and Staging/Production have different numbers too. E.g. my latest numbers are at:

iOS/Staging: v217
iOS/Production: v62
Android/Staging: v146
Android/Production: v61

It seems like the Sentry release names will eventually run into each other and cause problems because the label (v123) isn't enough to distinguish between Staging/Prod and iOS/Android.

Isn't this a problem? Or does Sentry somehow know how to distinguish?

Version: sentry-cli 1.44.3

[boennemann]

I'm seeing the same problem. I don't get why all the release name patterns for react-native related commands are hardcoded. This is completely breaking with promoting code-push bundles, too.

Also attaching commit information is a complete PITA, because the release name is not predictable with the hardcoded label postfix.

The same collisions will happen if you build the native version multiple times, as there the pattern is just $BUNDLE-ID-$VERSION. Change the JS code, build the same binary version again, collision.

I would love to change the release to be commit hash based, which I also found suggested in the docs.

How can we overwrite the release name patterns? Reading the source code it doesn't seem possible.

[HazAT]

The latest version of @sentry/react-native sends
bundleID+build as a format so e.g:
io.sentry.bla+1337 as the release.

This shouldn't be changed and the reason is our new Release Health feature https://forum.sentry.io/t/mobile-release-health/9248 which relies on that format for multiple reasons.

What should be changed is that we need to set these values:

iOS/Staging: v217
iOS/Production: v62
Android/Staging: v146
Android/Production: v61

into dist.

Therefore the artifacts shouldn't conflict.

[boennemann]

This shouldn't be changed

You say _shouldn't_ here, but the original issue reported is that we can't in the first place.

Also can you elaborate more on this dist field?

Are you familiar with promoting CodePush builds through environments?
The bundleId is not necessarily constant for any given jsbundle, as the jsbundle might be promoted or uploaded to a different CodePush environment.
This environment might have a completely different bundleId.

[hashinclude72]

wasted my whole day on this, aparantly this issue was first reported on 2017 and still no proper fix.

And please tell me about this dist field?

[StarryFire]

1. Put this just below Sentry.init in your codebase

codePush.getUpdateMetadata().then((update) => {
      if (update) {
        Sentry.setDist(`codepush_${update.label}`);
      }
    });

1. To deploy changes via codepush, run the following command

appcenter codepush release-react --sourcemap-output --app APP_NAME --output-dir ./build -d DEPLOYMENT_NAME

1. To upload the sourcemaps of the deployed codebase to sentry, run the following commands

export SENTRY_PROPERTIES=./PLATFORM/sentry.properties

./node_modules/@sentry/cli/bin/sentry-cli react-native appcenter APP_NAME PLATFORM ./build/CodePush --deployment DEPLOYMENT_NAME --release-name RELEASE_NAME --dist DIST_NAME

where,
APP_NAME is ${owner_name}/${codepush_app_name}.

DEPLOYMENT_NAME is the name of the deployment you want to deploy the changes under i.e. Staging/Production/etc. defined in your codepush app settings.

PLATFORM is the platform you want to deploy the changes for i.e. ios/android.

RELEASE_NAME for android is: ${applicationId}@${versionName}+${versionCode} and for iOS is: ${bundleIdentifier}@${version}+${build}.
This naming convention is mandatory for RELEASE_NAME because otherwise sentry's RELEASE Health feature won't work properly. For more details, look at https://github.com/getsentry/sentry-cli/issues/577#issuecomment-610272845
Also, because, when we build our release/staging app via XCode/Android Studio, Sentry always uses that release name (hardcoded by sentry) to upload our sourcemaps and so as not to make a new release on sentry for each codepushed version, we will put them all under one release name, divided by different distribution names i.e. DIST_NAME

DIST_NAME is codepush_${codePushUpdateLabel} where codePushUpdateLabel is the name of your codepush release eg. v21, v22, etc. You can check this out by going into your codepush app webpage on appcenter website and then Distribute -> CodePush -> Select your respective deployment
codePushUpdateLabel will be at the top of of the list since which is the update you just deployed on codepush. eg. codepush_v22

[hashinclude72]

hey, @StarryFire thanks man for this detailed response. I will give it a go.