Let's save that, File, Save. All right. Let's do the next one. The next one is to add a rest route. Now, this is going to be useful for us to test the end point and also reset the end point. So if we have to do some testing with the metrics, and we're trying to get an accurate result from the metrics, we can use this reset to basically bring the metric back down to zero. Now, that surrounds, so we can add it really anywhere in the block, but I like to keep buying routes together. So I'll add it right below the metrics route. That's around line 40 right below the /metrics. So if we read that, we're going to use a router again, it's going to route tests, slash count. Actually, that should say reset, that looks like it's an error in our instructions. So we'll fix that for next time. Then, just change that from test underscore count to reset. Then, that will execute prom.reset and send a message back with the current date so that we can see a response when we hit that particular route. Now, the next step here is about keeping your applications alive. If you remember what I said about running a production application, make sure that you're not using this for production. But, if you do take care of wanting to use your free time on your Heroku account. This is likely going to use up your account if you leave it running for a very long time. Basically, we are going to use a ping, an interval, this command called set interval to ping your two applications. We can add that right after the routes for reset. So we'll add it right there. So when your application starts off, if we have the app URL configured and the Prometheus URL configured, then the ping interface will be executed in that some new route as /ping. The response from that will be pong response. So every five minutes or so, this application, the Probot app will ping itself and it will ping the Prometheus server, and that'll keep both the Prometheus server and the Probot app alive so that you can consistently collect statistics beyond 30 minutes. Otherwise, if you wait 30 minutes and you haven't received enter responses on any of these interfaces or any builds, then the Heroku application will automatically shut down your applications on Heroku, and you'll lose your data. So this is to help us test beyond 30 minutes. So if you want to run a build and then come back in an hour, then you can come back and do another build and look at some statistics based on that. Now, because Heroku could gives us the 540 hours between these two applications, that'll probably cut your time down to around 14 days. So make sure you do File, Save to save your changes. Let's take a look again and here on instructions. Yes. So if we had npm installed, we could run npm run test. Or, we can just build this with a docker build and run it locally. We're going to skip those steps and we're going to use this technique for testing. We'll be able to deploy our Heroku app with a git push to the Probot app since Heroku for Probot is set up with a Git remote. We could also just merge our changes, but we'll do that as a final step. So let's go to the GitHub desktop and look at our changes. I'm on the wrong branch. So let's switch to the Prometheus branch. Actually, it must have switched here. Let's switch here. Okay, there it is. So here's all of our changes. Just a quick recap, we add a router so that we can hit in points. We added the prom clients so that we could collect metrics, so we can create a scraper, so that Prometheus can collect metrics. We're going to use a summary metrics type, and it's going to have labels. That's going to be the action label or name label. Actually, label would be things like completed. Name label will be the step which is usually Travis branch. Check underscore run status will be the runs status, which is, not sure if I remember. I think it's completed, this will be the word completed. We'll have to double-check on that and then check underscore brown conclusion that'll be success or failure. So this is really key for us in this particular label, because we'll be able to determine between success and failure labels. Then, repository full name. This is the Heroku or user where the repository leaves in the name of the repository, and then just the repository name without the full name. That'll be assigned to a register so that Prometheus can aggregates from data with that summary metric type and collect that data for us. It's actually not Prometheus, but it's the client will be collecting that for us. So the metrics implant will help us display the metrics that we gather at any given point. So Prometheus will by default, probably ping this metrics route every 15 seconds or so and collect some metrics. Then, the reset will be there for us to troubleshoot and do some debugging with our metrics. The ping interface will be used to keep our application alive. Then obviously, we'll have the actual interval that is keeping our application alive. These are synchronous threads that are running and pinging our application. We'll use the app URL and prom URL to set that configuration. So that'll be a little bit of configuration that we're going to do on the Probot app. Then finally, the real work which is capturing the checks API event called check underscore run and with the action called completed, so that we can make the observation of the actual Travis duration, and the way we're doing that to just to recap here, is that we're taking the started at time. Let's see if we can find that exact calculation there. Yes, we're taking the completed at time,and we're subtracting it from the started at time. We're using this date object to get us an actual number. Then, that's going to be returned as a difference in duration, which is a number of milliseconds. We'll be able to use that information to do some visualization of when the builds are actually executing. All right. So let's commit that. This is our Prometheus scraper. Just commit that and push up our changes. So that will begin another build on our Probot-hello application here. If we wanted to try this out, basically, there's actually, it's going to look at the package.json real quick. We did bumped aversion. So if we go look at Safari, and we go find our probot app. We'll see, let's just refresh that and make sure it's so 1.0.0. So that's great. So we can use that command here. Let's see if we can find it. There it is, Git push Heroku, the name of the branch that we're using, then the target which will be master. So at this point, if we just call the name of the branch, we used Probot underscore prom. So we can go back to our terminal window and make sure that we're here in this directory. Yes, we are. It says, your branch is up-to-date. I'm in the wrong directory. So let's go back to web. Here it is, Git status, as the name of our branch. So let's just copy the first part of this. Then, the name of our branch probot-prom. It looks like I got two underscores in there. Just double-check that. Yeah, looks like I did two underscores. So be careful with your underscores and then call them Master. I better add the extra underscore. There was that won't work. Git remote-v. I haven't hooked up my Heroku login here. Let's just Heroku login real quick, and browse here, we'll log in. Let's make sure we get back connected. We use the Heroku git and colon remote to load that back. I better specify the app. Let's go make sure we get the app name right. The app name is right there actually. Okay, great. So if I type git remote-v again, now I have that origin and we should be able to do the git push to test our change. Excellent. So this will just take a few minutes. We're going to let it build. I'll pause the video and then we'll be right back.
