With Sentry, we're able to tie errors to Git commits that likely cause the issue. This enables us to track who the issue originated with, what feature it's related to, and what exact code was being developed at the time. This feature is called Suspect Commits. First, to enable Suspect Commits, we need to create a remote version of our repo in GitHub.
If you haven't initiated your local project as a repo yet, You should run git init to do so. I already have my repo set up, so I won't hit enter, but that's what you would type in. Then you would want to add all your files and commit them. As a side note, if you aren't familiar with Git for version control, I really encourage you to learn more about it.
I've left a link in the description below. However, if you aren't familiar with Git and don't want to learn it at this time, you can go ahead and skip this lesson. Alright, now let's open up GitHub and create the new repo. I'll call the repo, Sentry Course.
And we can skip the description, leave it as public, and I'll hit create repository. Since we have an existing repository, I'll copy this bit here. Then we can paste it back in the terminal in our project. And hit enter.
With our project now available on GitHub, we've got to give Sentry access to it. To do so, in this Sentry dashboard, we'll navigate to Settings, Integrations, and find GitHub on the list. I'll click Add Installation. And now, Sentry is asking us for permission to install this app on our GitHub account.
I'll hit Install. I'll give it access to my personal account here. And really, I only want it to have access to the Sentry course repo. So I'll do that.
Also, you should probably read the permissions here, as you are giving permissions to Sentry to do things and access things and read things and write things to your GitHub account, so it's really worth knowing what they have access to do. Alright, I'll hit install. I'll confirm my password, and voila! Now GitHub is set up with Sentry.
Next, we'll need to set one more configuration option on the Sentry plugin for Veet. auto option to true. Since we're deploying from a Git repository, then we can let the Sentry V plugin set the commits automatically for us, saving us some time. That's pretty great.
Otherwise, we'd have to manually provide the repo and the commit, like this. Now, let's introduce a new error. This time, we'll just create a button on the About page. and I'll label it sendEmail.
Why not? And then, let's say that we've got a user object. Then, on the click of the sendEmail button, we'll try to access some non-existent email property on the user, and then try to call some kind of non-existent send method. Alright, now let's go update the package version, since the code has changed.
With that done, now we can add our changes to Git. and commit them, and finally push them up to GitHub. Now we can build the project and run it once more. I'll do this by typing npm run build and then npm run serve.
Over in the browser, I'll navigate to the about page and then trigger our error by clicking on the send email button. All right, let's see what it looks like now in Sentry. I'll visit the Issues page once again. And yep, there's our issue.
I'll click into it to see more info. Now, on the Issue page, we can see this section called Suspect Commits. And while we don't have the proper commit showing now, if we click the Show More button here, sure enough, the proper commit is listed. This is awesome.
This can really help us narrow down what is going on with our code, and what commit caused the issue. Also, if you didn't see the suspect commit right away, just give it a few minutes. It didn't show up for me right away either. With Sentry, we're able to tie errors to Git commits that likely cause the issue.
This enables us to track who the issue originated with, what feature it's related to, and what exact code was being developed at the time. This feature is called Suspect Commits. First, to enable Suspect Commits, we need to create a remote version of our repo in GitHub. If you haven't initiated your local project as a repo yet, You should run git init to do so.
I already have my repo set up, so I won't hit enter, but that's what you would type in. Then you would want to add all your files and commit them. As a side note, if you aren't familiar with Git for version control, I really encourage you to learn more about it. I've left a link in the description below.
However, if you aren't familiar with Git and don't want to learn it at this time, you can go ahead and skip this lesson. Alright, now let's open up GitHub and create the new repo. I'll call the repo, Sentry Course. And we can skip the description, leave it as public, and I'll hit create repository.
Since we have an existing repository, I'll copy this bit here. Then we can paste it back in the terminal in our project. And hit enter. With our project now available on GitHub, we've got to give Sentry access to it.
To do so, in this Sentry dashboard, we'll navigate to Settings, Integrations, and find GitHub on the list. I'll click Add Installation. And now, Sentry is asking us for permission to install this app on our GitHub account. I'll hit Install.
I'll give it access to my personal account here. And really, I only want it to have access to the Sentry course repo. So I'll do that. Also, you should probably read the permissions here, as you are giving permissions to Sentry to do things and access things and read things and write things to your GitHub account, so it's really worth knowing what they have access to do.
Alright, I'll hit install. I'll confirm my password, and voila! Now GitHub is set up with Sentry. Next, we'll need to set one more configuration option on the Sentry plugin for Veet.
auto option to true. Since we're deploying from a Git repository, then we can let the Sentry V plugin set the commits automatically for us, saving us some time. That's pretty great. Otherwise, we'd have to manually provide the repo and the commit, like this.
Now, let's introduce a new error. This time, we'll just create a button on the About page. and I'll label it sendEmail. Why not?
And then, let's say that we've got a user object. Then, on the click of the sendEmail button, we'll try to access some non-existent email property on the user, and then try to call some kind of non-existent send method. Alright, now let's go update the package version, since the code has changed. With that done, now we can add our changes to Git.
and commit them, and finally push them up to GitHub. Now we can build the project and run it once more. I'll do this by typing npm run build and then npm run serve. Over in the browser, I'll navigate to the about page and then trigger our error by clicking on the send email button.
All right, let's see what it looks like now in Sentry. I'll visit the Issues page once again. And yep, there's our issue. I'll click into it to see more info.
Now, on the Issue page, we can see this section called Suspect Commits. And while we don't have the proper commit showing now, if we click the Show More button here, sure enough, the proper commit is listed. This is awesome. This can really help us narrow down what is going on with our code, and what commit caused the issue.
Also, if you didn't see the suspect commit right away, just give it a few minutes. It didn't show up for me right away either.