Laravel: Using Travis CI on GitHub

I have been developing a Laravel project for some time to showcase, in a very concrete case, aspects and tips that I find interesting about the framework.

Once the unit and functional tests were set up, I wanted other contributors to be able to join the project and for me to see the results of the tests and PHP-CS-Fixer directly without having to run it on my development environment each time.

This is where Travis CI comes into play.

The Travis CI platform works closely with GitHub and is therefore very well integrated into the site. To install it, simply go to the settings of your project on GitHub and add Travis CI in the Integrations & services section.

On Travis CI, you need to authorize the application to access your GitHub. Now, when a branch is pushed or merged into the repository, scripts will be run on Travis CI, and you can see the progress via a terminal directly in your browser.

Well, I could talk at length about all the available features, but that's not the subject of this article. I redirect you to the documentation if you want more information on this topic.

So, how do I integrate Travis CI into my repository?

All the configuration for Travis is contained in a single file named .travis.yml. If the file is named differently, it won't work. It must also be located at the root of your project. Once you have pushed a branch containing this file, Travis will notice it and run the scripts, but otherwise, it will do nothing and everything will remain as before for you.

There are really hundreds of possibilities and configurations, but I just wanted to present a classic case containing tests with PHPUnit and syntax checking with PHP-CS-Fixer in a complete PHP project.

How to write the instructions?

As you can see, the file is in YAML format. The syntax is very basic, and everything depends on indentation.

I will use the file I use for my project as an example and detail it for understanding, but of course, you will need to adapt it according to your needs.

Language

First of all, you need to specify the primary language used in your project to create your test environment. At the very top of the file, you simply need to specify:

language: php

By default, Travis offers several test environments with pre-installed tools. The PHP environment installs all these packages, so you won't have to install them in the following scripts.

Versions

Next comes the version of the language you want to use. You can select several, and Travis CI will run the scripts independently for each version. This can be very practical to know the minimum version your application needs to function and to ensure that it doesn't change during your development (unless it's planned, of course).

You simply need to indicate the versions of the language you want to test in this form:

php:
  - 7.0
  - 7.1

Services

Several services are provided by default for each image. You just need to activate them, and Travis will handle the installation and configuration for you.

The list is quite comprehensive, but in our case, we only need MySQL. Of course, these services are pre-installed, but nothing prevents you from manually installing those of your choice.

To activate them, it's very simple:

services:
  - mysql

Cache (optional)

If your builds take too long to complete, it might be due to the lengthy download or setup of your dependencies. Fortunately, Travis provides a caching system to save the state of a directory between different builds. In our case, we want to keep the Composer dependencies from one build to another:

cache:
  directories:
    - $HOME/.composer/cache

The before_script

We now arrive at the critical part of our configuration. But before starting, we need to prepare the environment so that our build works.

For Laravel, this is limited to three steps. If you needed to install other tools as we saw in the services above, now is the time.

First, we need to install our project's dependencies via Composer, which is already installed by default, adding some flags to speed up the process.

before_script:
  - composer install --no-progress --no-interaction --prefer-dist --no-suggest

For the database, even though MySQL is now installed, we need to create a database. The complete documentation can be found in the database section on the official site. Note that you can connect to this database with the root or travis users and without a password.

We can add this line to our before_script:

- mysql -e 'CREATE DATABASE homestead;'

For these reasons, I have created in my project a Laravel environment configuration file specifically for Travis. This allows me to indicate to the framework which database to use with the correct credentials. Since PHPUnit uses the .env.testing configuration file by default, this allows me to replace the original file, used on my development environment, with the one specific to Travis during the builds.

- cp .env.travis .env.testing

Scripts

We can finally run our scripts. It's very straightforward; it's the exact equivalent of what you would do on a development environment:

script:
  - vendor/bin/php-cs-fixer fix --config=.php_cs --verbose --dry-run --diff
  - vendor/bin/phpunit

Notifications (optional)

By default, Travis sends an email at each step of the build, which can quickly become annoying. To disable notifications, you need to specify it in the configuration file:

notifications:
  email: false

Complete file

My configuration file at the end looks like this:

language: php

php:
  - 7.0
  - 7.1

services:
  - mysql

cache:
  directories:
    - $HOME/.composer/cache

before_script:
  - composer install --no-progress --no-interaction --prefer-dist --no-suggest
  - mysql -e 'CREATE DATABASE homestead;'
  - cp .env.travis .env.testing

script:
  - vendor/bin/php-cs-fixer fix --config=.php_cs --verbose --dry-run --diff
  - vendor/bin/phpunit

notifications:
  email: false

Conclusion

With this, you have the basics of a Travis configuration, and you can start working collaboratively without breaking everything.

Of course, the service allows you to do so much more, so I invite you to consult the documentation; it's very interesting and comprehensive.

And there you have it, you can now proudly display the little

[![Build Status](https://travis-ci.org/{ORG-or-USERNAME}/{REPO-NAME}.png?branch=master)](https://travis-ci.org/{ORG-or-USERNAME}/{REPO-NAME})

Thank you!