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:
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 justmypy
to run against all files.