Let's set up a continuous integration server so that we can automate the process of our build and our test suite each time new code is merged into our repository. So at the moment, if I run our test suite phpunit, excluding a couple skip tests that I need to address, everything should be returning green, and it is. So why don't we set up Travis CI, which is what I like to use. You might also look into a tool called CircleCI that I hear is great as well. I'm just a little more comfortable with this. However, it turns out somebody has already submitted a pull request for this, which is great. Robert. So let's see. This PR sets up the necessary configuration to work with Travis CI. So if we take a look at what he's added here, we have a .env.travis file. All right, so what it looks like is that here's our .travis.yml file. So think of this as the configuration for your Travis build. It specifies what versions of PHP do we want to run your code.

All right, so what it looks like is that here's our .travis.yml file. So think of this as the configuration for your Travis build. It specifies what versions of php do we want to run your code against. Is there anything we need to do first, before? What scripts do we need to run? Are there any services you need? Any other steps that we need to know about, basically. So we can see here each of these items represents a console command that Travis will execute. So in this case, the PR is saying, all right, take this file and we're going to copy it to .env, and that way it will take precedence when we run the test suite. Next, do a composer self-update, and then install all of our dependencies. Next, the script will generate a new application key, and then trigger the test suite. Okay, why don't we give this a shot? So I'm going to go ahead and merge this in, and on that note, we have two options here. We can do a merge commit, and that will take all

the test suite. Okay, why don't we give this a shot? So I'm going to go ahead and merge this in, and on that note, we have two options here. We can do a merge commit, and that will take all of the commits they've produced here and merge them into the main code base. There's also an option called squash and merge. So this will take all of their commits and basically squash them, if you can imagine your hands going together. You're going to squash them into a single commit, and then add it to our base branch. So why don't we take that approach? Now you'll see here, here are the two commits. They are now being squashed into a commit, and by default it's just going to take the name of the PR, or you can change it. So why don't we say add Travis CI integration, confirm squash, and merge them in. So now if we take a look at the main commit history, you'll see here, yeah, here's all we have. There's no merge commit, there's no record of all of the

code into the repository, because remember that that's what continuous integration refers to. We are continuously integrating all of our code, all of the code from across the team, into a single core repository. And then on top of that, we are automating the process of building that code and triggering the test suite to ensure that everything remains in sync. But anyways, we could wait for a new code to come in, or I think we can force a build here. Let's give that a shot. And of course, this is going to take a moment or two, because as you see here, it has to install all of the dependencies that were specified right here. So it has to do a composer install on its server. It has to set up PHP to be used. It has to run this command. It has to trigger phpunit. So you want to give that a few minutes. And really, remember, the idea here is you're not visiting this page all the time. This will happen automatically, and then we can

has to trigger phpunit. So you want to give that a few minutes. And really, remember, the idea here is you're not visiting this page all the time. This will happen automatically, and then we can reflect that within our GitHub repository. But anyways, let's just see here if we scroll down. All right, so it's doing a composer self-update. So it hit this step here. Next, it should do a composer install, and it is. So it's grabbing all of that. And remember, it knew what language we were using because we specified it here and here. If you want to test against PHP 7.2, then you could add a new item to this list here. All right, so let's come back up. All right, so it installed all of the dependencies. It's now generated a key, and it's running our phpunit test suite. There we go. Now, there were no errors, so that should return with a check. And if we scroll up, we get a green check. Great. So now we can click on our little status here,

unit test suite. There we go. Now, there were no errors, so that should return with a check. And if we scroll up, we get a green check. Great. So now we can click on our little status here, and we have a link to it. So if we load that in a new tab, we can see that the build for Counsel is currently passing. So why don't we grab a markdown ready version, and we can now add this to our README. How about here for now? There we go. Counsel build passing. Or maybe like that. All right, so let's add our README and git commit, or git commit with a message of add Travis badge. And finally, we will push this up. All right, so now if we come back, not only should we see our badge here, all right, test suite is fully passing, but we've also added new code, or we've merged in new code, so that should trigger a brand new build to make sure everything's still working. And here we go. I can take a look at build history, and that's

new code, or we've merged in new code, so that should trigger a brand new build to make sure everything's still working. And here we go. I can take a look at build history, and that's currently in the process of running. It's been going for about a minute 40. So if we scroll down, yeah, it's still doing that composer self-update. And that's it. So think of it this way. We've now instructed Travis, whenever we accept new code, I want you to run through these steps. I basically want you to set up a server, generate a key, run phpunit, do any pre or setup type work, and then tell me what the output is. Now let's review one more thing before we finish up. Let's set up a new branch, make a PR ourselves that will break the test suite, that will break the build in some way. Okay, so let's do this. git checkout a new branch feature/demo, because I'm going to delete all of this once the video is done. Anyways, I have a new branch. Let's just go to some something here.

Okay, so let's do this. git checkout a new branch feature-demo, because I'm going to delete all of this once the video is done. Anyways, I have a new branch. Let's just go to some something here. A User can filter any threads by a username. Okay, so yeah, let's imagine we made some kind of change to the code that will ultimately break the test suite. All right, let's see. git add test everything. git commit with add some feature for demo. And we'll push it up. git push to origin feature-demo. Okay, so now if we switch back to Chrome, we'll give it a refresh. We should now, yeah, we have this new branch here where I can see the commit that we made. Now if we switch over to Travis CI and go to build history, that has automatically triggered a new build. And if that's what you want, it's fine. You can also configure it to say only trigger Travis CI builds when code is added to the master branch and things like that. So that's definitely an option. But anyways, let's

request comes in. Well, we now have the functionality that shows, hmm, something with this pull request is breaking the code. The author of the PR either needs to make some tweaks, or we should go ahead and close the pull request. So let's say, sorry me, stop breaking the code base. Close and comment, and we're done. I'm also going to delete the branch. And that's all there is to it.