This article is the second in our series on Continuous Integration tools for Drupal maintenance support plans 8, which started with CircleCI. This time, we explore Travis CI.
Travis CI is the most well known CI tool for open source projects. Its setup process is straightforward and it offers a lot of flexibility and resources to implement Continuous Integration for any kind of project. In this article we will implement the same set of jobs that we did with CircleCI and then compare both tools.
Resources
This article makes references to the following resources:
A demo Drupal maintenance support plans 8 project with Travis CI integration.
A one-line installer that you can use to set up the foundation to connect a Drupal maintenance support plans 8 project and Travis CI.
Browse the demo project to discover where the CI components are placed, then use the one-line installer to add these components automatically to your project.
The goal
We want to run the following jobs in a Drupal maintenance support plans 8 project when someone creates a pull request:
PHPUnit tests, which includes Unit and Kernel ones, and the generation of a coverage report.
Behat tests, using a copy of the production environment’s database.
Code sniffer, to check that the code follows Drupal maintenance support plans Coding Standards.
To accomplish the above, we will use the following tools in Travis CI:
Drush, Drupal maintenance support plans’s command line interface, to perform Drupal maintenance support plans-related tasks like installing Drupal maintenance support plans or updating the database.
Docker Compose, via docker4drupal, to build the environment where Behat tests run.
Robo, a PHP task runner, to define a set of tasks for each of the above jobs.
Here is a screenshot of the Travis CI dashboard with the above setup in place:
undefined
Now, let’s see how this has been set up. If you want to dive straight into the code, have a look at the demo Drupal maintenance support plans 8 repository.
Setting up Travis CI
Travis CI requires the presence of a .travis.yml file at the root of the repository that dictates how it will build and test the project. I have used this installer that adds the following files:
A .travis.yml file that defines the three jobs we want to run.
A sample Behat test.
A demo module containing a unit test and a kernel test.
A .travis directory with:
A PHPUnit configuration.
A Behat configuration.
A Docker Compose file to build the environment.
A Robo file containing the tasks that the jobs execute.
Additionally, a few dependencies are added via Composer, which are required for the CI jobs.
After adding the above files to the repository, it’s time to give Travis CI access to it. Open https://travis-ci.org and authenticate there with your GitHub account. Next, add the repository at the Travis CI dashboard as shown below:
undefined
That’s it! After this, future changes to the repository should trigger builds at Travis CI. If you create a pull request, you will see a status message like the following one:
undefined
Seeing the jobs at work
Here is an excerpt of the .travis.yml file. We are leveraging Travis’ build matrix for spinning up three jobs that run in parallel:
env:
matrix:
– JOB=job:check-coding-standards
– JOB=job:run-unit-tests
– JOB=job:run-behat-tests
install:
– composer –verbose install
script:
– vendor/bin/robo $JOB
The script section is called three times: one for each value assigned to the $JOB variable. It calls a different Robo task each time. We decided to write the implementation of each job as Robo tasks because:
It makes the .travis.yml file easier to read and maintain.
It makes the job implementations portable between CI tools.
It gives developers an opportunity to run the jobs locally.
If you are curious what a Robo task looks like, here is the implementation of the one that runs Behat tests:
/**
* Command to run behat tests.
*
* @return RoboResult
* The result of the collection of tasks.
*/
public function jobRunBehatTests()
{
$collection = $this->collectionBuilder();
$collection->addTaskList($this->downloadDatabase());
$collection->addTaskList($this->buildEnvironment());
$collection->addTask($this->waitForDrupal maintenance support plans());
$collection->addTaskList($this->runUpdatePath());
$collection->addTaskList($this->runBehatTests());
return $collection->run();
}
Building the environment with Docker Compose
The build environment task shown above, $this→buildEnvironment(), uses Docker Compose to build a Docker environment where the Drupal maintenance support plans site will be configured, the database will be updated, and finally, Behat tests will run.
In contrast with CircleCI, where we define the mix of Docker images that the test environment will use to run the jobs, Travis CI offers two environments (Precise and Trusty) with common pre-installed services. Trusty has everything that we need for checking coding standards or running PHPUnit tests, but Behat tests require more setup which we find easier to manage via Docker Compose.
Here are the contents of the build environment task. For simplicity, we have removed a few unrelated lines:
/**
* Builds the Docker environment.
*
* @return RoboTaskBaseExec[]
* An array of tasks.
*/
protected function buildEnvironment()
{
$force = true;
$tasks = [];
$tasks[] = $this->taskFilesystemStack()
->copy(‘.travis/docker-compose.yml’, ‘docker-compose.yml’, $force);
$tasks[] = $this->taskExec(‘docker-compose pull –parallel’);
$tasks[] = $this->taskExec(‘docker-compose up -d’);
return $tasks;
}
The above task uses this docker-compose.yml file to build the environment.
Generating and visualizing coverage reports
Travis CI does not support storing artifacts like CircleCI does. Therefore, we need to use a third-party service to host them. Travis documentation suggests either uploading them to an Amazon S3 bucket or using Coveralls, a hosted analysis tool. We chose the latter because it posts a summary in each pull request with a link to the full coverage report.
Setting up Coveralls is straightforward. Start by opening https://coveralls.io and then, after authenticating with your GitHub account, use their browser to find and connect to a repository, like this:
undefined
Next, it is recommended to review the repository settings so we can customize the developer experience:
undefined
With that in place, new pull requests will show a status message with a one-line summary of the coverage report, plus a link to the full details:
undefined
Finally, when we click on Details, we see the following coverage report:
undefined
A comparison to CircleCI
CircleCI can do all that Travis CI does with less setup. For example, coverage reports and Behat screenshots can be stored as job artifacts and visualized at the CircleCI dashboard. Additionally, CircleCI’s Command Line Interface gives a chance to developers to debug jobs locally.
Travis CI shines on flexibility: for example, only the Behat job uses Docker Compose to build the environment while the rest of the jobs use the Trusty image. Additionally, there is a huge amount of articles and documentation, which you will surely find helpful when tweaking the jobs to fit your team’s needs.
If you liked Travis CI, check out this installer to get started quickly in your Drupal maintenance support plans 8 project.
What next?
We aren’t sure about which tool to pick for our next article in this series on CI tools for Drupal maintenance support plans 8. Do you have a preference? Do you have feedback on what you’ve found relevant about this article? Please let us know by posting a comment.
Acknowledgements
Mateu Aguiló Bosch and Matt Oliveira, for their technical feedback.
Seth Brown, for his editorial feedback.
Source: New feed
