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.
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
name: CI Tests Run on: [pull_request] jobs: run-tests: runs-on: ubuntu-18.04 container: image: prooph/composer:7.2 services: redis: image: redis ports: - 6379:6379 steps: - uses: actions/checkout@v1 - name: Copy .env file run: php -r "file_exists('.env') || copy('.env.testing', '.env');" - name: Install dependencies run: composer install -q --no-ansi --no-interaction --no-scripts --no-suggest --no-progress --prefer-dist - name: Generate application key run: php artisan key:generate - name: Create database run: | mkdir -p database touch database/database.sqlite php artisan migrate - name: Run tests run: vendor/bin/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!
