Understanding releases and revisions (with containers)

Integrations
1

With the old integration for Python/Django (raven) it used to be somewhat straightforward to add the revision information in a 12-factor app:

RAVEN_CONFIG = {
    'dsn': env('SENTRY_DSN', default=None),
    # Automatically configure release based on information from Git
    'release': env('REVISION', default=None),
}

The REVISION was an environment value we added to the container image in the build process.

With the new, universal integration (sentry-sdk) the concept seems to have changed. Revision information is not attached to an application, but is meant to be supplied by the sentry-cli, presumably - by an API call issued by the CLI - in the build pipeline.

I’m not sure I’m missing something in the picture. When, say, my Kubernetes/OpenShift cluster decides to fall back to an older image than the one that I recently shipped via my pipeline how does Sentry ensure the exceptions thrown are related to the appropriate commit?

2

Can a Sentry developer, customer success engineer, platform evangelist, … comment on this? :grimacing:

3

I’m not sure what you mean. The new SDK is configured similarly and there’s no dependency on sentry-cli. Even the link you pointed to shows using sentry_sdk.init which is equivalent.

The sentry-cli components do extra on top of this for commit metadata and more explicit release management. This works the same as it did with raven.

So there’s no change in behavior here.

4

Oh, I think I see some of the confusion. Our documentation pushes over to sentry-cli but all of these old options can still be defined in sentry_sdk.init similarly.

See: https://docs.sentry.io/error-reporting/configuration/?platform=python