It's common in continuous integration to run some form of test coverage report to ensure you're hitting a minimum coverage percentage. Now if you want to do that, you need a coverage driver like Xdebug. You'll need to enable Xdebug, make sure you've edited the php.ini, and then of course execute the coverage report against the test suite. So let's go to our test.yaml file and let's add the coverage flag. I'll also set a minimum here using the min flag of 75% and let's just push this up and see what happens. Whoa, whoa, whoa! That just worked?

Whoa, whoa, whoa! That just worked? We have a coverage report? But what about enabling Xdebug, editing the php.ini, making sure the extension's turned on, setting the Xdebug modes? We didn't do any of those things and yet it worked. What's going on? I know what's going on because I did the research. I'm going to tell you. It turns out GitHub Actions is helping us.

I'm going to tell you. It turns out GitHub Actions is helping us. GitHub actually provide this runner images repository where you can gain insight into the images you're using on GitHub Actions. So let's take a look at Ubuntu 24.04, which is what we're using. I'm going to scroll down a little bit here until we hit this beautiful subheading, PHP tools. See, you're not actually dealing with a bare bones installation of Ubuntu. GitHub have installed additional tools on top to make your life easier and one of those tools is PHP.

GitHub have installed additional tools on top to make your life easier and one of those tools is php. So out of the box, you have access to the PHP 8.3.6 binary. Now you might be saying to yourself, Luke, why did we use that set up PHP action if we already have PHP and composer and PHPUnit installed out of the box? It seems a little wasteful. Well, although we do have PHP installed out of the box, we only have one version of PHP installed and we'd have to set up all of the different extensions we require manually. It just makes it so much easier to have that easily configurable through the setup PHP action.

It just makes it so much easier to have that easily configurable through the setup PHP action. So that's why we use that. But yeah, technically you have access to PHP right off the bat. And note this little line here, both Xdebug and peak of extensions are installed, but only Xdebug is enabled. In other words, out of the box, Xdebug is already turned on and configured, which is why when we attempt to run a coverage report, it works. Xdebug is already there. It's waiting.

X debug is already there. It's waiting. It's ready. And it says, Hey, I can do coverage. I'll provide you with a report. Hold in a second though. When we turn Xdebug on, doesn't that slow php down? Yes, it does. It slows php down, which means out of the box, your php is going to run slower in GitHub Actions than it otherwise would because Xdebug is on.

It slows php down, which means out of the box, your php is going to run slower in GitHub actions than it otherwise would because Xdebug is on. Thankfully, set up PHP actually makes it fairly simple to disable Xdebug when we don't need it. Here's our set up PHP and composer action. We can pass another piece of input to this action called coverage. You could, for example, say that you want to use Xdebug here. You could say that you want to use peak of here, but because Xdebug is available and enabled out of the box, the default value here is actually Xdebug. There's a third value we can pass, which is none, and that will disable Xdebug entirely.

enabled out of the box, the default value here is actually Xdebug. There's a third value we can pass, which is none, and that will disable Xdebug entirely so that php runs as quickly as possible. I want the default to be none and I want to use Xdebug only when required. So here's what I'm going to do. I'm going to come up to the inputs at the top of our composite action and I'll create a new coverage input. Let's create a description for this. The coverage driver to use. We'll say that it's not required, so false, and we'll set a default of none.

The coverage driver to use. We'll say that it's not required, so faults, and we'll set a default of none. Then we can make use of that in our setUp PHP and composer action. So we'll use the GitHub syntax to say that we want to grab inputs and we're looking for that coverage input. So now by default, Xdebug will be turned off and PHP inside the GitHub action will run as quickly as possible. But if we want to use it as we do inside our tests, we'd come to the setUp action and we'd say that we want to use the Xdebug coverage driver and everything should work. Let's test that theory by pushing this up and making sure nothing's broken.

and we'd say that we want to use the Xdebug coverage driver and everything should work. Let's test that theory by pushing this up and making sure nothing's broken. Well it still passes and it still generates a coverage report. We meet the minimum of 75% so the action is green. So that's good. We've not broken anything. Let's make sure that when we merge this and we run another workflow like Laravel Pint, that doesn't break now that coverage is set to none. And we're passing with flying colors. If we come down to the set up action, you can see in set up PHP, we do indeed correctly

And we're passing with flying colors. If we come down to the setUp action, you can see in setUp php, we do indeed correctly set coverage to none for this particular action, meaning Xdebug will be disabled. And if we come down a little further, yep, Pint is still running exactly as expected. So there you go. An interesting bit of trivia about GitHub Actions. Xdebug is installed and enabled by default. And if you want to eke out the best performance, make sure you disable it whenever you don't need it.

need it.