Hey y'all. Welcome back. We have recently added two amazing tools for a project php sent and Rector, and now it's time for us to configure CI so that we can with php sent catch errors very early. And with Rector, make sure our code is always up to the standard we defined. So let's show into the code and see how we can set that up. Okay, so first things first. I added two small errors to your application.

Okay, so first things first. I added two small errors to your application. The first one in our php send playground, I'm passing recipient as the generic type here, but we are working with invoices. So if I run php send, it will fail. And then for Rector, I reverted this closure back to a regular closure, not an arrow function. So if I run Rector, it should fail and we can see Rector complaining about this file.

So if I run Rector, it should fail and we can see Rector complaining about this file. However, if I go to my pull request, you're gonna notice that we have tasks passing. If I look at linear quality, it is passing, everything's passing. And if I look at the tasks, they're also passing. So we have to fix this because this PR should clearly be failing. Let's go back to our code.

because this PR should clearly be failing. Let's go back to our code. And first I want to fix something else. You notice that we have to run a lot of commands to run all of our tasks. We have to run php artisan tasks, we have to run reactor, and we have to run php stan. Let's try to condense all of that into a single command. So let's go to the scripts section within our composer.json file and let's add a new script.

So let's go to the script section within our composer.json file that Chase on file and let's add a new script. We're gonna call this test and this is going to run a few commands. The first one is it's going to run php stan. It is then going to run php artisan test on dry run mode. And this is because we don't want to actually run php artisan test, we just want to make sure there are no violations on ci. And finally it's going to run php artisan test. So if I come here

And finally it's going to run php artisan test. So if I come here and say, composer test, it should run php center first. It's going to fail if we go here and just fix this and rerun composer test, it is now failing on Rector. And of course if we go ahead and fixed fracture, it will run everything and pass. There we go. So let's get this back to rad. Let's undo those changes.

There we go. So let's get this back to rad. Let's undo those changes. Let's rerun it and make sure it fails. Awesome. And now I'm going to go to the CI pipeline and you can see this is pretty simple. This is a real simple GitHub workflow. We're just setting it up and then running the phpunit command. We're just gonna change this with composer task. That's all. And I'm going to commit and push this.

We're just gonna change this with composer task. That's all. And I'm going to commit and push this. Okay, so CI has run for the commit of hours. Let's take a look at it. If we go to tests, we can see it's failing on PHP sent. So I'm gonna go ahead and fix PHP sent. Let's do invoice here. And I'm just going to push this. Okay, our latest commit has come through and it's also failing. Let's take a look at the details.

and it's also failing. Let's take a look at the details. Okay, we can see that php sent, ran, there were no errors, then Rector ran and there were errors. So that's why we have reactors set up with try run. It is not going to try and commit the changes, but it will return with one if there are changes to be made. And this will alert you or your team that they have to fix something. And this is a very easy fix.

or your team that they have to fix something. And this is a very easy fix. So let's go back to our code and let's go ahead and add a composer command here real quick. We're gonna call this Rector, right, to be very explicit that we're going to be overriding files. And this is just going to call vendor/bin/rector. So let's run composer rector, right? Sweet, and let's commit this Rector changes. Okay, see I just finished.

Sweet, and let's commit this Rector changes. Okay, see I just finished. And we can see that it is now passing. So if we look at the details, we can see that we ran php artisan test, we ran Rector, and then we ran our test suite. Now, whenever a PR comes through, or a commit is pushed, we can run php artisan lint to check for possible problems, and we can run Rector to check for code quality. And in Rector's case, it is just running a command.

and we can run Rector to check for code quality. And in Rector's case, it is just running a command. If you wish to, you could even have Rector commit the change itself automatically update your code on the pr. But I chose not to do this at this time. Now that we have Rector PHP stand in our task passing, it is saved to go ahead and merge this vr. Awesome. Now, I've seen how easy it is to integrate PHP stand in Rector to your workflow. And a cool thing is that you can also run them in parallel.

to integrate php stand in Rector to your workflow. And a cool thing is that you can also run them in parallel. Right now we're running everything sequentially. We run php stand, then Rector, then the task suite. But we could also run php stand, Rector, and the task suite in parallel. And if one of them were to fail, everything else would stop as well. So if while your task were running php stand were to fail, we would just bail the entire process.

So if while your task were running php stand were to fail, we would just bail the entire process. Pretty cool stuff. As usual, I hope you enjoyed this lesson. See you in the next one.