For specific setup instructions, see the links to the left.
When a Rollbar project is connected to a git repository, stack traces will include links to each file in the code version where the error was most recently activated.
To ensure that stack traces will link to the correct code version in your git repository, make sure to send the full git SHA in the
code_version attribute when reporting exceptions to Rollbar. See the instructions for your Rollbar SDKs for specific instructions on using
When a Rollbar project is connected to a git repository, the list of commits included in each deploy will include URLs so you can view the diff for each commit as well as the entire deployed code version.
When a Rollbar project is connected to a git repository, any commit that has been merged to your master branch but not yet deployed will be highlighted at the top of the Deploys screen.
By adding an appropriately formatted message when committing a code change, you can tell Rollbar to automatically mark an item as resolved as soon as the commit is deployed to production.
git commit -m 'resolves rb#12345'
To learn more, check out Resolving Items via commit
In order to let our servers know that you want to try linking your stack trace to the files on your git repository, you should send the
server.root key. A lot of the time that can be
/, to indicate that all files can be linked to a file in your repository. Other times, you can set it to directories or package name your source files are prefixed by.
If you have source maps enabled and your stack trace is prefixed by
webpack:///./, you may have to set
server.root = webpack:///./ to complete source linking.
All official Rollbar SDKs can send this key. See the documentation for your Rollbar SDKs to learn exactly how.
An additional benefit of correctly setting
server.root is that vendor code in your stack trace, portions that don't come from a subdirectory of
server.root, will be collapsed. It also improves how Rollbar groups that error. We strip off
server.root from your code where possible before using the filenames as part of the fingerprint. This means you can host the code from varying locations on your servers, and still correctly see otherwise identical errors as part of a single group.
Code that is considered in-project because of the
project_package_paths key will not be linked to your repository at this time.