Continuous Integration

Sentry uses a variety of continuous integration services to help ensure we don't accidentally break the application.

Travis CI

Travis CI 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.

Clearing Travis Cache

Build caches can be cleared in the Travis cache page.

However, there are multiple issues with that:

• The "Delete all repository caches" button does not work when a large amount of caches has to be deleted. Instead, type the following into your browser devtools console on that page:

  JavaScript

  Copied

  Travis.__registry__._resolveCache[
    "config:environment"
  ].skipConfirmations = true;
  btns = document.getElementsByClassName("delete-cache-icon");
  i = 0;
  while (i < btns.length) {
    btns[i].click();
    i++;
  }

  Or this works too and is prettier:

  JavaScript

  Copied

  window.confirm = (m) => true;
  Array.from(document.getElementsByClassName("delete-cache-icon")).map((e) =>
    e.click()
  );

• Cache deletion is asynchronous. After telling Travis to delete caches, it takes a while for that deletion to actually apply.

  After retrying your build, it may fail again. Most of the time this is because your issue has nothing to do with caches. But sometimes it's Travis's fault. Inspect the build logs to see if Travis possibly fetched the "deleted" cache (ctrl-f for "cache"). If so you can try clearing caches again and waiting a bit before retrying your job yet another time.

GitHub Actions

We use GitHub Actions to supplement front-end builds and apply automatic style fixes. We're also trialing it as a way to run acceptance tests.

Percy

Percy checks the outputs of acceptance tests and reports on changes in rendered results. See the testing chapter for more information

Freight

Freight is how we deploy our applications to staging & production.

Reverting / Rolling Back After a Bad Deploy

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.

Docker images

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/onpremise:

• getsentry/sentry:<sha>, getsentry/sentry:<short_sha>, or getsentry/sentry:latest to pull from a commit in getsentry/sentry master
• us.gcr.io/sentryio/sentry:<sha> to pull from a commit in any other branch or PR

Troubleshooting CI

You might also be interested in troubleshooting the dev environment.

Problem:

ContextualVersionConflict while installing stuff in Travis CI.

Solution:

Purge the Travis cache. How? See above.

Problem:

When pushing your build to staging and you it fails the Ensure test image step on Travis.

Solution:

You probably forgot to push your branch on Sentry to GitHub.