Homework check. How do you get on? Well, let me briefly show you the solution. Instead of using the event type of pull request, we will use push. Push allows us to specify a branch that we're interested in and we're going to listen for the main branch. And that's all we've got to do. Now, any time code is pushed into the main branch, which happens when you complete and merge a pull request, this workflow will be executed. The workflow is going to go ahead, run Laravel Pint, detect any changes to files,

The workflow is going to go ahead, run Laravel Pint, detect any changes to files, and then push them back into the main branch to complete the process. It wasn't that hard, was it? Now that we have commenting on a pull request and linting out of the way, why don't we turn our attention to the majority use case for continuous integration, running your test suite? Again, let's not start from scratch here. Let's copy and paste Laravel Pint, and I'll call it tests.yaml. We can change the name to tests,

Let's copy and paste Laravel Pint, and I'll call it tests.yaml. We can change the name to tests, and we want to go back to executing this on a pull request with the defaults being absolutely fine for our use case. We can change the ID to maybe run-tests on Ubuntu, and the steps will be quite similar. We want to check the code out. We're not having to push back into the repository so we can remove the reference. It simplifies it.

so we can remove the reference. It simplifies it. We do want to set up php and Composer. PHP 8.3 sounds good. Composer v2 sounds good. We don't want to install Laravel Pint, but we do want to install the project dependencies, so let's make sure that we run composer install at this stage. Then, of course, we want to run the tests, which would be php artisan test,

Then, of course, we want to run the tests, which would be php artisan test, but as you know, when you clone a Laravel repository, there are a few steps you need to take first. So, for example, one of those steps would be copying the .env.example file to .env and then generating an application key. Let's make sure we've done that. So after installing dependencies, but before running the tests, we'll create a new step, maybe prepApplication,

So after installing dependencies, but before running the tests, we'll create a new step, maybe prepApplication, and then in the run command here, we'll use the pipe operator to allow for multiline, then we can say copy .env.example to .env, followed by php artisan key:generate to create our application encryption key. Then we run our tests. I'm going to do that in compact mode. I'm using pest in this particular project,

I'm going to do that in compact mode. I'm using pest php in this particular project, so I don't want massive output inside GitHub Actions, and I can remove this final step because we don't need to push anything back to the repository. One last thing, when we do composer install, I'll use the -q flag to make it quiet, and I'll also use the --no-interaction flag because, obviously, in GitHub Actions, there's no way we can actually interact with the console.

because, obviously, in GitHub Actions, there's no way we can actually interact with the console. I think that should be enough for a very basic test runner, so let's push it up and see if it works. Okay, I've got good news, and I've got bad news. The good news is the workflow ran. The bad news is, well, all but one of the tests failed, and they failed for the same reason. We're using a SQLite database, but there is no database/database.sqlite file.

We're using a SQLite database, but there is no database/database.sqlite file because that's not part of the source code. Now, if you're using MySQL, Postgres, and you want to test against those databases, don't worry. We're going to cover that in the next episode, but for now, how do we solve this? There are one of two ways. In prep application, we could just create it, so touch database/database.sqlite.

In prep application, we could just create it, so touch database/database.sqlite. No issues doing that whatsoever. That should work without problems. However, if you go to phpunit.xml, you'll have seen these two commented out lines before, no doubt. In other words, you can override dbConnection and dbDatabase to use an in-memory SQLite database. It's faster than using the file variant. Of course, you could just uncomment these lines and commit that.

It's faster than using the file variant. Of course, you could just uncomment these lines and commit that, but there's another way to do it that's perhaps a little less invasive. In our runTest step, we can override environment variables, and we can set them to whatever values we want. For example, we can set dbConnection to SQLite, and we can set dbDatabase to, and I'm going to wrap this in quotes because of the colons, memory. This will basically override whatever's in our .env file.

colon, memory, colon. This will basically override whatever's in our .env file. It will override whatever's in our phpunit.xml file, and it will force our database to be an in-memory SQLite database. Let's push this up and see if it's fixed our problems. More good news and more bad news. The good news, the errors have disappeared. The bad news, we have a whole new set of errors to worry about. This time, vpManifest not found. Depending on your project, you may or may not get this error.

This time, vpManifest not found. Depending on your project, you may or may not get this error. If you get the error, there is a simple fix. You go to your IDE. You're going to go into Tests, TestCase, Override setUp, and then inside here, after doing the parent setUp, you want to say this without vt, push that back up, and that should fix the problem. And fix it, it did. You can see that we've actually executed our test suite in 4 seconds,

And fix it, it did. You can see that we've actually executed our test suite in 4 seconds, which is wonderful news. That might not be the case for your application. You might still be getting errors. Check to see what those errors are, but I'm willing to place a bet on the fact that it's to do with a missing php extension. Thankfully, that php setup action actually allows us to define extensions inline,

Thankfully, that php setup action actually allows us to define extensions inline, which it will go ahead and install. And if you're wondering which extensions you need to install, well, the Laravel documentation will tell you for one, but you could also go to laravel/framework on GitHub, and if you go to github/workflows/tests.yaml, they have that exact same action, and they've defined a list of extensions. Now, no, you don't need all of these extensions,

and they've defined a list of extensions. Now, no, you don't need all of these extensions, but it's a great start, and if you just want to be sure that things are going to work, drop it in there. Be my guest. It's really not going to do any harm in the long run, especially when we cache those extensions in a future episode. So more than likely, if you're not using something like Redis or you're not trying to send email from your tests.

So more than likely, if you're not using something like Redis or you're not trying to send email from your tests or anything weird like that, everything should be working. But what if you are using a third-party service? What if you're using MySQL and you want to test against MySQL? Well, let's talk about that in our next episode.