Sentry uses a variety of continuous integration services to help ensure we don't accidentally break the application.
GitHub actions is our primary CI system and runs our tests on every pull request and on merges to master. It is required that tests pass before changes can be merged.
Freight is how we deploy our applications to staging & production.
If you've deployed something bad, you'll need to do the following:
- Deploy the most recently known good commit that succeeded ASAP. Keep an eye on this as deploys MUST finish, otherwise it's possible some web machines will still be stuck on the bad deploy's code.
- Inform #team-engineering that you're rolling back a bad deploy, and that no one should deploy getsentry master until the issue is resolved.
- Fix the issue, and get it merged into master.
- Deploy the fix, and verify that the issue has indeed been fixed.
- Inform #team-engineering that it is safe to deploy getsentry again.
We use Google Cloud Build to build our Docker containers. Every single commit (including from PRs) gets built, tested and becomes available at
us.gcr.io/sentryio/sentry:<sha> with no retention guarantees. Every push to
master gets built, tested and pushed to Docker Hub permanently. You can set
SENTRY_IMAGE to the following, when working with getsentry/self-hosted:
getsentry/sentry:latestto pull from a commit in getsentry/sentry
us.gcr.io/sentryio/sentry:<sha>to pull from a commit in any other branch or PR
You might also be interested in troubleshooting the dev environment.
When pushing your build to staging and you it fails the
Ensure test image step on Travis.
You probably forgot to push your branch on Sentry to GitHub.
For historical reference, we used to use Travis and Percy which have been replaced by GitHub actions and a GitHub action respectively.