Setup PHPUnit Tests on Pull Request for Laravel with GitHub Actions

Recently, Github released Actions beta for developers to let them try it.

Github actions are a way to automate your workflow in many ways. You can use some events triggers to do something. These events can be anything like a branch push, pull request open/push, and so on. I will not dig deeper into this now because it’s not the scope of my article.

github actions

via.

However, when discovering them, I asked myself: Can I use it to run PHPUnit tests on my Pull Requests, to avoid using external tools like Travis CI? I love Travis but hey, let’s play with it.

The answer is yes. Here is how I did it and how I created a workflow for it.

But first, some basics.

What is a Workflow?

A Workflow is an automated process you can create to tell Github that it must do something when something else happens. This may involve everything like testing, building, deploying, and so on. Workflows are stored under the .github/workflows directory in your repository, as .yml files.

Once they are versioned in the repo, Github will read them, validate them, and finally run them when the specified condition is triggered.

Ok, how do I make it?

I will copy/paste mine and then explain it.

Note: this is specific to Laravel. My app uses the 5.8 version of the framework.

Note 2: I prepared a .env.testing file with some specific settings I want to use when running PHPUnit.

Let’s see what we have:

  • name: no need to explain it. It’s just the name I gave to the workflow;
  • on: this is the condition you want to check to fire the workflow. In my specific case, I wanted to trigger a test run at every pull request open/push, to link this action launch as a condition to let me merge my PR branch (more details here);

At this point, I put my job inside the jobs item of the file. I named it run-tests. This is not something standard, and you can choose the name you want here.

Let’s see what we have inside a single job item:

  • runs-on: ok, here we can specify the OS we want to run our tests on. I use Ubuntu 18.04 in my production environment, so I decided to use the same while running tests;
  • container: here, we can select the container we want to run our tests on. I decided to use this prooph/composer image to have everything I need for a Laravel app. I used the 7.2 version to reflect what I have in production;
  • services: here, you can specify some extra services to be used during tests. In my specific case, I added a Redis instance because I have some functional tests that I need to cover a complete use case of my app;

The preparation part is done. Now…

The Steps

Steps are the most atomic part of your workflows. As you can see from the snippet, they are a sequence of commands I run to prepare everything and, finally, run tests.

The only exception is the first one, uses/checkout. You can find more about it here: https://github.com/actions/checkout.

And that’s it!

The icing on the cake: Github will automatically add the status check for every pull request from this moment on, and will re-run tests at every push on your branches (if a related PR is open).

Hope you will enjoy it!

Che cos’è questo Laravel Vapor e perché non vedo l’ora di provarlo

Una delle cose che mi affascina di Laravel (e che nel tempo mi ha fatto continuare ad usarlo per una marea di progetti) è il suo ecosistema.

Un paio di settimane fa ho mandato in review la mia prima app Shopify, creata con React per il frontend e, ovviamente, Laravel per il backend. Prossimamente ne parlerò meglio.

Grazie a Forge, nell’arco di circa due ore di lavoro ho messo su un server di stage ed uno di produzione, automaticamente collegati al push sui rispettivi branch su Github.

Grazie ad Horizon, nel giro di pochi minuti mi sono ritrovato con un’ottima interfaccia per monitorare l’esecuzione dei vari job.

Inutile dire che quando ho sentito parlare di Laravel Vapor durante l’ultimo Laracon (al quale non sono mai andato e forse è il caso di porre rimedio alla cosa…) la curiosità è schizzata subito alle stelle.

Quindi… cerchiamo un attimo di capire di cosa si tratta! Continue reading

The 2018 Mighty Laravel Application 20 Optimization Ideas Checklist


Here we go! Your Laravel application is now in production. You are online, ready to start making a lot of mecha-gazillion dollars.

Roses are red, violets are blue, tests are green and you feel so cool.

First user. Ten users. One hundred users. A thousand users! Suddenly, the more you go forward, the more your application becomes slower.

What should you do? Well… Devil is in details.

After some searching, I decided to create this list of 20 tips you can use to boost your Laravel application to a new level. Continue reading

Monitoring a Laravel Application with Telescope

I am always excited when a new Laravel ecosystem product comes out. I am not a fanboy, I have always been skeptic and critic about some parts of the framework when I don’t like them, but there is something (among many others) I love about Laravel: its pragmatism.

So, every single time they release something new I am 100% sure that it’s something that can be useful, no matter if paid or not (the cure the team put in it makes nearly impossible to feel the difference).

Today I want to talk a little bit about Laravel Telescope, a debugging tool for Laravel applications. On the Telescope Github page is defined as an “elegant debugger assistant”.

Continue reading

Il mio nuovo package per Laravel 5.6: Circuit Breaker!

Di tanto in tanto mi capita di buttare giù due righe in PHP e scrivere dei package “ispirati” a qualcosa che ho visto a lavoro, o di cui magari ho avuto necessità nella stesura di questo o quel side-project. Qualche giorno fa, a lavoro, mi sono ritrovato a parlare con un collega del Circuit Breaker pattern, di cui si può trovare un’ottima spiegazione qui.

Circuit What?

Niente di complesso, ad essere onesti. Fondamentalmente si tratta di un pattern grazie al quale è possibile, in parole poverissime, “wrappare” una funzione/oggetto in modo tale da poterne monitorare lo “stato di servizio”. Per capirci meglio facciamo un esempio:

  • immaginiamo di avere un’integrazione con un gateway di pagamenti per il nostro store/applicazione;
  • in caso di malfunzionamenti abbiamo un meccanismo di fallback, che ci permette di segnare gli ordini che non possono essere processati se il gateway è giù;

Implementando un circuit breaker monitoriamo l’esito delle chiamate al gateway di pagamento. Se più di X chiamate in un certo periodo T non vanno a buon fine, allora possiamo marcare per un certo lasso di tempo il nostro gateway come “failed” ed usare direttamente il meccanismo di fallback, senza dover aspettare tutte le volte il gateway che, sappiamo, ormai è andato.

Abbiate pazienza, è sabato sera e non ho una gran fantasia.

Interessante! Cosa c’entra con Laravel?

C’entra perché chiunque può sviluppare la propria “versione” di un circuit breaker. Nel mio caso, ho deciso di creare un package per Laravel (dalla 5.6 in poi) che mi permetta di realizzare velocemente una cosa del genere.

Continue reading