Understanding releases and revisions (with containers)

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

    '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?