Sentry CLI: Deploy in project A creates deploy in project B (shared release)

[jeengbe]

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

1. Create a release X for projects A and B (monorepo, thus A and B share the same commit hash)
2. Deploy project A to environment E
3. Observe that a deployment for project B in environment E was also created

Expected Result

A could be a service (that runs in all environments) and B a cronjob (that only runs in prod). Both A and B come from the same monorepo and when A is deployed to staging, a staging deployment for B is also created.

Instead, when deploying A to staging, the deploy should be only created for A and has nothing to do with B. They share the same release, but not deploys.

Actual Result

I run the manual CI job "deploy A to staging" and I get (both mail and in Slack):

and the Sentry dashboard shows the same.

Product Area

Releases

Link

No response

DSN

No response

Version

No response

[getsantry]

Assigning to @getsentry/support for routing ⏲️

[jeengbe]

The release also has both deploys attached to it on the release overview page.

[szokeasaurusrex]

Steps to Reproduce

1. Create a release X for projects A and B (monorepo, thus A and B share the same commit hash)
2. Deploy project A to environment E
3. Observe that a deployment for project B in environment E was also created

Hi @jeengbe, just to confirm, are you performing these steps using the Sentry CLI? If yes, could you please provide the exact commands that you ran, so I can assist you better? Thank you!

[jeengbe]

Hi! The script is essentially:

Build:

sentry-cli releases new $RELEASE
# Sometimes the Sentry API fails, but that shouldn't stop the build process (https://github.com/getsentry/sentry-cli/issues/1928)
sentry-cli releases set-commits $RELEASE --auto --ignore-missing || true

docker build

sentry-cli sourcemaps inject /app/dist
sentry-cli sourcemaps upload --release $RELEASE /app/dist

sentry-cli releases finalize $RELEASE

Deploy:

sentry-cli releases deploys $RELEASE new -e $ENVIRONMENT -t $(($end - $start))

[szokeasaurusrex]

Thank you for the quick reply @jeengbe. One more thing that would be helpful: if your repo is public, would you be able to share a link to it, so I can better replicate your setup? If it is private, that is also okay; I can try to create a similar setup.

[jeengbe]

I unfortunately can't share it.

[szokeasaurusrex]

@jeengbe Are you running this build script once (i.e. to create the release for both projects simultaneously) or twice (i.e. within each project individually to create the release separately for each project)?

[jeengbe]

I run the build script twice in parallel (both projects have a separate project in Sentry so that's the only way I found to create the release for both Sentry projects)

[szokeasaurusrex]

The -p project argument is documented in the sentry-cli releases new --help; however, the help text does not state that multiple projects can be specified. Perhaps we could improve the help text

[szokeasaurusrex]

@jeengbe After looking into this issue some more, I now believe that there are three things simultaneously preventing your deploy from being associated specifically with Project A. These can each be corrected as follows, and all of them need to be corrected in order for the problem to be resolved:

1. When running the sentry-cli releases deploys new command, you need to specify the project you wish to deploy with the --project argument. Otherwise, by default, the release is deployed for all projects associated with the release. You will need to fix this problem yourself by updating your script that runs the command.
2. The Sentry CLI needs to attach the project(s) specified in the sentry-cli releases deploys new command's --projects argument to the API request it sends to the Sentry backend, so that the Sentry backend can associate the new deploy with the specified projects. Currently, although the CLI accepts the --project argument for the command, the argument is ignored. This problem is fixed in fix(deploys): Use --project argument #1930, which I intend to release soon.
3. Lastly, the Sentry backend needs to correctly display when a deploy is only associated with some of a release's projects. When testing fix(deploys): Use --project argument #1930, I noticed that currently, the latest deploy is visible on all of a release's projects, even if the deploy was only created for some of the release's projects. It appears that the code that processes the API request to create a deploy handles the projects correctly, so my guess is that there is something going wrong when the UI displays the latest deploy for a project in a release. I will reach out to the team responsible for the Sentry backend to see what might be wrong here.

Thank you again for reporting the issue, and I hope we can get this sorted out soon!

[jeengbe]

@szokeasaurusrex Thanks for the extensive response.
This is slightly off-topic now, but how do releases for packages work. When I create the release like "service-a@hash" and open the release details view, I get this:

where version is separate from package. Is that how you're supposed to handle several services deployed from the same monorepo commit? I feel like this whole are could be a bit better explained. I've checked the docs several times now, and I still only have a vague idea of how releases relate to commits, packages/services, projects, deploys, source maps. I'd be happy to assist with further feedback.

[szokeasaurusrex]

I've checked the docs several times now, and I still only have a vague idea of how releases relate to commits, packages/services, projects, deploys, source maps.

Thanks for this feedback – in fact, I agree with you completely. I have also needed to reference the docs while investigating this issue, and I found it difficult to find the necessary information in the docs. So, I have created an issue for us to improve these docs.

Regarding your specific question about packages and versions, the documentation states that the package@version syntax is recommended for mobile platforms. However, the same docs state that release names are arbitrary, so feel free to use this syntax for non-mobile platforms as well, if you find it helpful.

[szokeasaurusrex]

@jeengbe Just wanted to let you know that we have an internal ticket to get point (3) in my previous comment fixed! I will update you once I have more information.

[szokeasaurusrex]

Hey @jeengbe, we now have a public issue on the getsentry/sentry repo to address point (3) from above. Once that issue is fixed, everything should work as expected!

Since I have already fixed point (2) in the Sentry CLI, I am going to close this issue. If, once getsentry/sentry#64793 is completed, you are still experiencing the same problem, please reopen this issue and I will investigate further!

[szokeasaurusrex]

Reopening this issue, because we had to revert #1930 to provide a temporary fix for #1939. Will try to figure out how we can introduce the functionality provided by #1930 in a non-breaking manner

[szokeasaurusrex]

We will wait on implementing a fix here until getsentry/sentry#64793 is completed, so we can more easily test the changes

[nhsiehgit]

Thsi should now be resolved via getsentry/sentry#65587

Please reopen if youre still seeing an issue 🙏

[szokeasaurusrex]

Reopening, we still need to implement the fix in the Sentry CLI – see my comment above

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀