Sentry-cli: error: Couldn’t not find the SHA of the previous release in the git history.

[sgametrio]

Hey everybody,
I'm using Sentry on a repository where we have several branches that upload source maps to Sentry, each time with a new release.

When calling these CLI commands:

sentry-cli releases new ${CI_COMMIT_SHA}
sentry-cli releases set-commits --auto ${CI_COMMIT_SHA}  # <--- here I get the error

It happens that sometimes we get the error

error: Couldn’t not find the SHA of the previous release in the git history. Increase your git clone depth.

And if I increase the git depth, it showserror: No commits found. Leaving release alone.

It has to be said that when merging into master we are squashing commits and that could be the cause of our problems, but we can't figure out exactly because sometimes the set-commits command just work as expected.

[kamilogorek]

--auto is a flag, and it doesn't accept any additional value, so this last ${CI_COMMIT_SHA} is ignored.

edit: My bad, it's an actual release name and it should be there.

If you squash or rebase git history, then as you already mentioned there's a chance that hashes will be overridden, and we won't be able to find old release reference. If you cannot change that, then you'll most likely have to explicitly tell the CLI which hash is the one that you want to use as the base, eg.

sentry-cli releases set-commits "$VERSION" --commit "[email protected]"

[vinnymac]

@kamilogorek your advice is certainly helpful, but the first thing you mention is that --auto takes no additional value and that ${CI_COMMIT_SHA} is ignored. The documentation for the CLI has examples that show this exact usage however.

Is the example wrong, or does the auto flag actually accept a value?

I see competing examples here.

If this wasn't the official documentation I wouldn't be concerned, but others might be led astray here if an inconsistency exists.

[kamilogorek]

@vinnymac good catch, updated my comment. I misread the command 😅 Thanks!

[x-yuri]

@kamilogorek @sgametrio Actually I believe sentry-cli shouldn't fail because of a rebase. Just store in a release a list of associated commits (unless you already do), and look in the git history not for a release name, but for every commit in turn. Unless you find the commit in the previous release, check the one before that. Maybe 2 releases is generally enough. But you can add a switch to specify "how much is too much." You want releases to not branch? Add a --force switch. Or at least document the way to use sentry-cli that doesn't choke on rebases:

VERSION=$(sentry_cli releases propose-version)
sentry_cli releases new -p "$sentry_prj" "$VERSION"
sentry_cli releases set-commits --auto "$VERSION" || {
    PRV_VERSION=`curl -sS \
        -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
        "$sentry_base_url/organizations/$sentry_org/releases/$VERSION/previous-with-commits/" \
        | jq -r .version`
    sentry_cli releases delete "$PRV_VERSION"
    sentry_cli releases set-commits --auto "$VERSION"
}

We can discuss the issue if you feel like it.

If you cannot change that, then you'll most likely have to explicitly tell the CLI which hash is the one that you want to use as the base, eg.

This seems reasonable, but in practice seems useless, unless you do it by hand in your local repository. Sorry for being blunt. Where will I find the now non-existent commits on a CI server to determine the base commit? In the reflog?

And actually I have a number of questions for which I don't expect to receive answers. Except for possibly here? Anyways, I'm open for suggestions. The first one is that I'm reluctant to install the GitHub application. Judging from the wording it seems like once I do, I can never go back. Then you suggest using cli over api. Why is that? You say that releases are global per organization. Is using commit hashes safe? The documentation makes one think one should do something different if one doesn't want to install the GitHub application. But from I can see, the difference only in the result (more info on Sentry probably).

[JustDoItSascha]

Is there any progress here? The set-commits command is failing here, but we haven't done a squash or a rebase. Is there any possibility to get around this problem? Because right now the only way to exit this loop hole is to completely disable set-commits command, right? Or is it possible to say "use auto, but if you don't find something, just take the last commit in history"?

[karatekaneen]

I ran in to this issue on our CI system. It boiled down to that it only fetched a shallow copy of the git repo.
I solved it by running git fetch --unshallow before the sentry_cli releases set-commits --auto "$VERSION".

Hope this can help someone.

[klarkc]

@karatekaneen did you found a way to fetch without unshallowing? This make a bottleneck in our CI. Would be nice if we shallow fetch only needed commits for sentry-cli

EDIT:

I found a way to it with help of bash and sentry-ci:

LAST_RELEASE=$(sentry-cli releases list | sed -n 6p | tr '|' '\n' | sed -n 3p | tr -d '[:space:]')
LAST_RELEASE_DATE=$(sentry-cli releases info $LAST_RELEASE | sed -n 5p | tr '|' '\n' | sed -n 3p |  sed 's/^[ \t]*//;s/[ \t]*$//' | tr ' ' '\n' | sed -n 1p)
git fetch --shallow-since=$LAST_RELEASE_DATE

EDIT 2:

If some1 name releases with git describe, and also set commits in each release, you can also use this be able to do in a CI enviroment:

COUNT=30; cc=$COUNT; while [[ $(git tag | wc -l) < 1 ]]; do git fetch --depth=$cc; cc=$(expr $cc + $COUNT); done ;

This script will "git fetch" until find a tag and be able to git describe, and also to be able to set commits. Set COUNT to a pagination value (in this example it increments fetch range by 30 commits). If your last tag was a sentry release, the SHA will be in git history, so also solve this issue.