Environment

SaaS (https://sentry.io/)

Version

No response

Link

https://sentry.io/organizations/sentry/discover/homepage/?field=organization.slug&field=count%28%29&name=All+Events&project=1&query=message%3A%2A000000000000000000000000000000000...%2A&sort=-organization.slug&statsPeriod=14d&yAxis=count%28%29

DSN

No response

Steps to Reproduce

1. Create a new release
2. Manually associate commits with release using partial SHA like so: sentry-cli releases set-commits --commit meisen-haus/test-commits@f915d32..4ebad56 "testing-commits"
3. Observe that the logs from sentry-cli show revisions are resolved appropriately but with the incorrect full SHA
4. Finalize release, see that the response from Sentry shows 0 commits upon release finalization (this is because we've already failed to fetch them)

This appears to be related to the how the Oid is generated by the Rust Crate git2. Specifically this function, where git2::Oid::from_str() is called. You can see from the test that this is the expected behaviour, where the partial SHA is formatted as an Oid.

That being said, it looks like we use the CommitSpec value (which includes org/repo-path@partial-sha) when looking up the revision in the release integration which is why they're resolving in the logs when running sentry-cli:

  INFO    2023-01-13 16:05:38.483685 -05:00 Resolving 4ebad56000000000000000000000000000000000 (meisen-haus/test-commits@4ebad56)
  INFO    2023-01-13 16:05:38.483700 -05:00   -> found matching revision 4ebad56000000000000000000000000000000000
  INFO    2023-01-13 16:05:38.483706 -05:00 Resolving f915d32000000000000000000000000000000000 (meisen-haus/test-commits@4ebad56)
  INFO    2023-01-13 16:05:38.483712 -05:00   -> found matching revision f915d32000000000000000000000000000000000

When the PUT request is made to update the release in Sentry we pass the full SHA (which has incorrect trailing 0's). Sentry then attempts to fetch commit data to populate the Release in the releases view but fails (see linked Discover query at top of Issue)

Expected Result

Partial SHAs did work in the past. Customers expect it to continue working.

Despite this, we have recommended users use the full SHA for some time it seems:

Note that you need to refer to releases you need to use the actual full commit SHA. If you want to refer to tags or references (like HEAD), the repository needs to be checked out and reachable from the path where you invoke sentry-cli.

Actual Result

Passing partial SHAs now result in "Unable to fetch commits" notification emails.

Workaround

Instead of using the manual --commit flag when using the CLI you would simply make the equivalent API request that the CLI abstracts.

Here's how I set it up for my repro:

curl https://sentry.io/api/0/organizations/<org_slug>/releases/<version>/ \
 -H 'Authorization: Bearer <auth_token>' \
 -X PUT \
 -H 'Content-Type: application/json' \
 -d '{"refs":[{"repository":"<github_org>/<repo>","commit":"4ebad56","previousCommit":"f915d32"}]}'

Some caveats for this approach is that sentry-cli abstracts retries and backoff strategies for handling API rate limits.

It's worth underscoring that in the case of GitHub at least, Sentry is still able to fetch commits using partial SHAs.

As far as I can tell sentry-cli has been passing partial SHA's with trailing 0's since at least v1.9 in 2017.