- [Instructor] Okay, welcome back! In this demonstration we're going to carry on from where we left off in the previous demonstration, but this time, we're going to set up a triggering of our build, based on any time that we commit our source code back into GitHub. 

So up until now, all our demonstrations have been manually triggered. That is, within Jenkins, we've had to click the build now link. So let's get started. Again, we log in to Jenkins. We navigate in to our previous build job, BuildJob3. We'll click on Configure. And we'll quickly review the current settings. So at the moment, we've indicated that it's a GitHub project found at this URL. We've set up source code management and specified the repository URL. And then down towards the bottom, we specified some basic execution commands to do the third-party library install as well as the transpilation process. This time, we'll scroll back up, and under build triggers, we'll enable the GitHub hook trigger. 

We'll then jump over in to our GitHub repository, and this is the repository that we're building within Jenkins. We then click on settings, navigate to Webhooks, click on the Add webhook button, then under the payload URL, we'll paste in a link back to our Jenkins server. So our server is running at this public IP address, port 8080, and we need to specify the path github-webhook. We specify the content type as application/json. Under "Which events would you like to trigger," we're going to trigger on just the push event in to our repo. We leave the Active enabled, and we click the Add webhook. Next, we go back to Jenkins, and we'll apply the settings, and we'll click save. We then navigate back to the react-webapp, and we'll copy the clone url. 

We'll jump back into our terminal. We'll make a new directory called JenkinsDemo. We'll navigate into it, and we'll git clone our repository. We'll navigate into the react-webapp directory, we'll do a directory listing, and from here, we'll start up visual code, and we'll make an edit. We'll navigate into the source directory, and this time we'll open up App.js. And on line 22, we'll just tag on version 2.0. We'll save the file, we'll jump back into our terminal, we'll do a git status. We can see we've updated or modified the App.js file. A git commit - a to add - m for message. updated App.js. Enter. So now that we've set up our web hook, when we make any connects back to our repository, GitHub in the background will make an HTTP post to our Jenkins web server. But for our Jenkins web server to accept it, we need to update the associated security groups to whitelist the GitHub public IP addresses. 

Now the public IP address range that GitHub uses can be found at this documentation link. So if we navigate to it, you'll see here that you can retrieve the list of IP addresses from the this Meta API endpoint. So let's click on this. And here, we can see the three address ranges that GitHub uses for its webhook mechanics. So let's jump over into the AWS console. I'm running the Jenkins master server as an EC2 instance. So I've already pre-created a security group that has these three address ranges in it. So on my EC2 Jenkins instance, I'll select Networking and Change Security Groups. Here, I'll attach the GitHubHooks security group. If we click on it, click on the Inbound tab, we can see that each of the address ranges have been added as an inbound rule to port 8080. 

Okay, so with everything in place, we'll select our Jenkins web server. We'll refresh this page. You'll notice that we still have only one build job that has been executed. We now jump over into our terminal, and we'll do a git push. So we'll push our updates into our GitHub repository. Okay, that is completed. We'll jump back into Jenkins, and we'll wait for a bit. So here we can see that a trigger has happened, and that it's now executing build job two. So in summary, what we've seen here is that we're able to commit to GitHub and automatically trigger a build within Jenkins, so no longer do we have to do a manual build now. This is a really important concept that you need to understand and reapply when you build your own CICD pipelines. 

The point is, anytime that you commit to your single source of truth, your source repository, you should perform an automated trigger of your build pipeline to validate any check-ins into your source repository.