set_commits: use (commit) range based on previous release/deployment of given env

[blueyed]

It would be useful if commits could be set based on the previous release for the given environment, instead of the latest release.

That would allow to have granular / more correct assignments of commits for a testing/staging/production workflow, where releases to testing (e.g. deployed when merging into the master/main branch) would have a small number of commits, whereas the set of commits for a (pre-)release to staging then is bigger (but includes all the ones from testing being released to staging only now), and production typically has the same set of commits as the release to staging then.

Currently it appears to be that the creation of the release for testing assigns a small set of commits to the release, and then the same set (typically only one from a merged PR) is used for the later release to staging/production.

I've only found out just now that environment is optional with the GitHub Action (https://github.com/getsentry/action-release/issues/19, https://github.com/getsentry/action-release/pull/36), and will trigger a deployment, which might have interfered with / caused the behavior I am seeing/describing above. So I'll test it without specifying the environment, but suspect the issue might persist, given the docs that say:

If you also want to set a previous commit instead of letting the server use the previous release as the base point you can do that by setting a commit range

(Assuming that a new set_commits: prev_env setting might make sense, I'd probably still like not having created a deployment automatically if environment is provided, so this would maybe have to be controlled through a separate setting then)

[armenzg]

I'm having the same problem.

The set of commits included in a release get into a bad state if you have more than 1 environment reporting a release.

I've been getting 20 commits included in some releases and 0 on some other ones. Some of those 20 commits are from 3 months ago when I've had dozens of releases in the last week.

Where's the code that determine which commits should be included? I could try to fix it.

[Tofandel]

Bump here, I have a production and development branch each creating their own releases via pipelines but because there is no way to set which environnement to use when using sentry-cli releases set-commits $SENTRY_RELEASE --auto it fails to find commits in one of the branches because the history differs

Could not determine any commits to be associated with a repo-based integration. Proceeding to find commits from local git tree.
error: Could not find the SHA of the previous release in the git history.

Any workaround or option planned to fix this?

[laurenz-glueck]

@kamilogorek I noticed that your implementation of passing the environment to the set-commits command is currently on hold (https://github.com/getsentry/sentry-cli/pull/1145).

But for this issue here it would be enough to allow passing a custom commit range to the GitHub action. This should already be possible within the Sentry CLI right?

So would it be possible on your side to implement this here or could I try to provide a PR for that use case?

[kamilogorek]

This should already be possible within the Sentry CLI right?

Correct, CLI supports providing a commit range format. --commit "[email protected]"

So would it be possible on your side to implement this here or could I try to provide a PR for that use case?

I don't have enough spare time right now, but feel free to ping me if you need some assistance writing a PR :)

[gdborton]

@armenzg (i see you as a recent committer) @kamilogorek (you're in thread)

I just got bit by this, we're seeing too many commits come through in our production environment and it's going to make it difficult to investigate the source of original issues.... any chance someone at sentry could take a look at fixing this? Or provide some pointers for how to do so?

[brianthi]

Hey folks, unfortunately this is a feature enhancement we don't have bandwidth to take on at the moment. Ideally this is a feature added onto the Sentry CLI, and this project can then update to use the latest CLI version. Backlogging this request for now.