Workflow

You may also be interested in sentry vs. getsentry.

Testing Sentry commits in Getsentry

If you need to deploy to a staging environment: use ./bin/bump-sentry <sha> to update the committed version. Note that this will likely create a merge conflict so you'll want to merge just before updating:

Copied
git pull origin HEAD --rebase
./bin/bump-sentry deadbeef
git push origin HEAD -f

If you only need to validate CI: When you create a PR add requires <PR link> to the body of it. The getsentry/action-get-dependent-pr github action will pick up this value and update the sentry revision during CI. This is meant as a temporary measure to quickly validate a change -- one should commit backward and forward compatible changes in sentry since commits cannot be merged in lockstep.

NOTE: If you notice after opening it, edit the PR body and then push a new commit.

Fast reverting a change

If a merged PR in sentry or getsentry needs to be reverted immediately (such as during an incident or to un-break CI) the [Trigger: Revert] label can be applied to the PR. A GitHub action will process the label and apply the revert directly to the primary branch.

Python typechecking

We're slowly working to add typing to our Python codebase, using mypy to check types. While we do that, there are a few useful things to know:

  • As you create or work on Python files, please add typing where you can. If possible, try to follow the Python typing best practices, which may mean you also have to add from __future__ import annotations as the first line of your file. For more information about using types in Python, see the typing docs.

  • Check that the file you're modifying is not on the exclude list from pyproject.toml. In other words, you need to opt-in the file for type checking to happen.

  • To test types locally, you can run mypy path/to/file or just mypy to run against all files.

You can edit this page on GitHub.