Now, what's next? It means this application is ready to receive events. It's looking for issues, and whenever a new issues opened up it's going to put a message into the issue that says, "Hey, thanks for opening and this issue, it worked." So let's go back to our application and make sure that we actually do this. So in the GitHub.com LeoPoppy organization, we're going to look at the probot-hello. Right now there's no issues enabled, so click on settings, let's turn on issues that adds a new tab to the repository called issues. If we say new and we just put in a test issue here, we're going to submit the issue, and hopefully probot will receive the event from our application, and we'll see that message show up in a second with a response. It's not showing up. Let's go see what might have gone wrong. If we go back to the index.js and we look at the logs, we see that there was no events received here. So that's interesting. I expected something to show up here. So this is great. This is where troubleshooting wire webhooks aren't working becomes important. So if we click on the LeoPoppy organization, and choose settings, and click on the GitHub apps section and choose edit here. Now we can go to the advanced section and start looking at what's going on with the web events that are being sent. Let's go back to our app. GitHub apps, and we choose advanced, and let's try to redeliver this. Hey, that time we got a response. So the body is okay, and the request is made. Now, if we go back to our application in our repository GitHub.com/LeoPoppy, and we choose probot-hello, and we choose the issue, let's take a look at the issue we open. We're going to close this issue, and we're going to open a new issue. So this is our second. Second test will submit a new issue. Hopefully now we're sending and receiving webhooks to our application. So if we go back to the LeoPoppy, choose settings, and set the GitHub apps, and we take a look at our GitHub app choose Advanced. We can see the last event was set at 12:07, and it was a recent delivery. So it's possible that the webhooks aren't being sent on issues. So let's go make sure that's not the case. So if we scroll through this and choose permissions, repository issues, oh, no access. Let's grant access. Read write, and we'll save that data. Let's try it one more time. So if we go back to repositories, probot, issues and let's close this issue. We're going to open a new issue. Third time's the charm. We're going to receive a webhook notification if an issue is open. So to confirm that, let's go back to the probot app to see if it receives or sent to notification. So click settings, we'll go down to our GitHub app, edit, advanced, and there's still no notification. It's possible that even though we asked for the permissions and we configured the permissions here for read write, I wonder if we subscribed to the events. User permissions, yes we need to subscribe to events. So we turned on issues and issue comments so that we would receive events, and we'll turn that on again. Fourth time's the charm. Let's try. Let's try it. So close issue, new issue. Travis four. Here we go. Now let's see. We should have received the event by now, let's go look at the settings for the application one more time under GitHub to apps, edit, and advanced. Still no events. Install app, let's look at the configuration. Oh, look at this, we're requesting more permissions. So it just doesn't happen for free, you actually have to accept the new permissions. So now we can see that we have these new permissions there. So let's choose repositories, issues, and we'll close this issue, and open a new issue, and submit the new issue. Look at that, probot finally responded. Thanks for opening this issue, it worked. So let's go see how that webhook event happened. So if we go to the LeoPoppy organization choose settings, and we go back to GitHub apps, and we choose edit, then we can choose advanced, and we see the webhooks starting to show up. So the webhooks show us the post and the response from the server, and they show us the payload that we're sending. So this helps us as developers to develop the application that's going to be needed to interact between the third-party application that we create. For Travis, this is what the Travis application development team sees for debugging their application. So if we go back to glitch and we choose to look at the glitch application in the logs. Let's turn on and off the logs. We can start seeing some of the information that we're posting and the responses that we're getting back and forth. So this is additional debugging information that help us determine what might be going wrong with our code. So as you can imagine, using webhooks to interact with applications like our continuous integration system or any other part of your GitHub repository that you want to change and create some automation for continuous integration, is as simple as just setting up your first application and hosting that application somewhere where you can start doing anything you can imagine to improve the productivity and the feedback clips for your development teams. So that's webhooks. So what did we cover? We looked at what it meant to have a GitHub application, and start hosting your open source or your private repos on Travis-ci.com instead of Travis-ci.org. We looked at how to create our first GitHub application. Then we looked at the webhooks delivery system to see how notifications are sent back and forth between that GitHub application and the permissions that interact with the actual GitHub application on your particular repository or organization where you install it. That's how Travis is basically managing the interactions between the events that are being created in your pull request, and the actions that it takes to execute on the Travis-ci.com website with your repository to do continuous integration. So thank you very much.
