Sentry-cli: Releases and Sourcemaps of different projects get mixed up

[philipooo]

I noticed that when you have two project and both project have a release with the same name, the sourcemaps appear in both project releases after uploading them to one of them.

Meta

• sentry-cli 1.38.1 (win)
• sentry 9.0.0

Repro

1. Create two projects e.g. project-1, project-2
2. Set ENVVAR: SENTRY_AUTH_TOKEN, SENTRY_PROJECT, SENTRY_ORG, SENTRY_URL
3. Create a release sentry-cli.exe releases new 0.0.0.1
4. Upload sourcemaps sentry-cli.exe releases files 0.0.0.1 upload-sourcemaps --ext js --ext map ./sourcemaps/ --validate --no-rewrite --url-prefix ~/
5. Repeate steps 2-4 by using --url-prefix ~/test

Result
project-1 and project-2 contain a release called 0.0.0.1 with the artifacts ~/sourcemap.js.map AND ~/test/sourcemap.js.map

Expected
project-1 and project-2 contain a release called 0.0.0.1. project-1 contains the artifact ~/sourcemap.js.map and project-2 contains the artifact ~/test/sourcemap.js.map

[jan-auer]

This is expected behavior. Releases are tied to the organization and not a single project. So when naming releases with their version number, I would suggest to prefix it with either some bundle identifier or the project name. Example myapp-1.0.0.

[philipooo]

Thanks for the fast response. Can you tell me what is the idea behind this behaviour?

[jan-auer]

The original idea behind this design was to allow synchronizing releases across multiple projects. The source maps associated to that release would then automatically be used by all project, for instance.

[philipooo]

Am I correct that only the sourcemaps are shared by releases with the same name or is the release itself is also shared?

[stripathix]

Question: I have two projects A(Website) and B(Cordova mobile app). Both projects have same files. Right now I am first uploading my JS/Sourcemap files first to Project A and then I am uploading same files to Project B.

Do I really need to do it twice? Or Uploading JS/source-maps to Project A will be shared with Project B also. Release keys are the same for both projects and are under the same organization.

[nodkz]

@jan-auer It's really strange behavior.

We are using the following commands:

SENTRY_PROJECT=$APP_NAME-$APP_ROLE // eg. iam-server-corp, iam-server-public
SENTRY_RELEASE=$APP_NAME-$APP_REVISION // eg. iam-server-191218-ce44919b
echo -e "Sending sourcemaps for SENTRY_PROJECT: ${YELLOW}$SENTRY_PROJECT${NC}"
sentry-cli releases -p $SENTRY_PROJECT new $SENTRY_RELEASE || true
sentry-cli releases -p $SENTRY_PROJECT set-commits $SENTRY_RELEASE --auto || true
sentry-cli releases -p $SENTRY_PROJECT files $SENTRY_RELEASE upload-sourcemaps --rewrite . || true
sentry-cli releases -p $SENTRY_PROJECT deploys $SENTRY_RELEASE new -e $APP_ENV || true

According to these cli commands - it's very strange that we use sentry-cli releases with provided project value for uploading source-maps. And they are not project-specific.

Global releases blow my mind 🤯, cause any sentry account may contain different projects with the same app versioning strategy (eg. 1.0.0, 1.0.1 etc.). And now I'm forced to add prefixes to all my releases and also provide app prefix with every error. And every record error now contains the long ugly release strings (something like iam-server-191218-ce44919b instead of 191218-ce44919b).

It's better to store short revision ids in DB for performance reasons. And have double or more copies of source-maps for every project.

[kamilogorek]

Closing the issue, as it seems like the original issue has been partially resolved or there is a working solution. I'd prefer someone to create a new issue with a fresh description if it's still an issue.
Please do not hesitate to ping me if it is still relevant, and I will happily reopen and work on it.
Cheers!

[gaurav5430]

The original idea behind this design was to allow synchronizing releases across multiple projects. The source maps associated to that release would then automatically be used by all project, for instance.

In what scenarios could we have 2 different projects tracking the same release and the same sourcemaps?
For example, I have a multi tenant web app, and I send out the same release for all the tenants. Currently I have a different sentry project for each of the tenants with the same release number. I do face this problem where source maps uploaded to one project are visible across all the tenant projects. This is not helpful, because although the release is the same, there are some variables that do change across tenants in build time and hence the source maps are different. So in my case, I am tracking the same release across different projects, but not the same sourcemaps.

Just trying to understand if the files are in the releases are the same, in what scenarios would we need multiple projects ?

[kamilogorek]

Just trying to understand if the files are in the releases are the same, in what scenarios would we need multiple projects ?

@gaurav5430 kinda. Releases are "buckets" for multiple projects. So you can have a release "MangoJalapeno" which includes multiple projects like "Frontend", "Backend", "Database" and so on, so forth. All release files are available for every project within it. However, if you want to release let's say "frontend" to multiple instances, eg. prod, dev, staging and want to make a distinction between mutiple same files, then you can use dist option in the CLI (eg, --dist prod) and then environment option in your sdk (https://docs.sentry.io/error-reporting/configuration/?platform=javascript#environment)

This is how it'll end up in the UI:

[gaurav5430]

But in what scenarios do you need to have access to frontend release files in the backend release project?

I am trying to understand why this decision was taken?