Tomas Votruba has a new post to his site sharing some of the ways you can get the most out of Travis-CI, the popular build service, for your PHP applications.

Travis CI is the most spread CI in checking open-source projects.

Do you want to know how to use it 3x faster? How to make Travis generate code for you? And how to make your tokens safe?

He breaks down his suggestions into a set of seven tips:

• Skip x-debug
• Deliver PR Checks Fast
• Use ENV vars
• Use Travis to do More Just Watching
• Rebuild your GitHub Pages Daily
• Stay Secure
• Make use of Composer Scripts

For each item in the list he includes an example of what's required, either a change in the Travis-CI configuration, code, or in the Composer configuration.

Marcel Pociot has a recent post to his site showing how you can set up builds on the Travis-CI service for your Laravel Nova packages. Laravel Nova is the recently released product from the Laravel creators that provides an administrative dashboard.

Today Laravel announced that Laravel Nova can now be installed via composer. This works by providing your nova.laravel.com username and password as credentials for composer, as well as adding a custom Laravel Nova composer repository to your composer.json file.

[...] This is great news, as this does not only simplify updating Laravel Nova, but it also allows Nova tools/package developers to add continuous integration to their projects! But there is still a problem: we do not want to provide our Laravel Nova credentials in our open source repository. But how can we solve this?

Marcel then walks you through the process of using Travis-CI's encrypted environment variables to protect your credentials. He shows how to install the travis Ruby gem to get the travis command line tool, encrypt the values and update your Travis-CI configuration (.travis.yaml) to pull those into the build.

TJ Miller has written up a post for his site sharing a method he's created to verify the compatibility of a package in Laravel based on the version of Laravel installed.

I’ve been working with Honeybadger to build a new set of PHP integrations. I would like to write more about that soon, however, I feel like I’ve stumbled across something that could be useful to others. I wanted to share it as soon as I could.

For the Laravel package, I was aiming for Laravel 5.5 and newer support as it is the latest LTS version. [...] In hindsight, I don’t think that I actually ever tested it against a 5.5 install. I relied on the CI process to make those verifications for me.

[...] As Laravel 5.7 is now out, I needed to add support to both the package’s composer configuration and verification in CI. [...] Now that I am supporting three versions I felt that I needed a more specific way of verifying compatibility with different versions of Laravel.

He shares his initial version of his Travis-CI configuration, running tests on PHP 7.1 and 7.2 with the prefer-lowest flag. In order to make it easier, he updated this based on what he'd seen in other packages: adding a matrix that runs PHP 7.1 through 7.3 against versions 5.5.x, 5.6.x and 5.7.x to ensure compatibility across all variations. His resulting build looks something like this.

In a post to his site Sergey Zhuk shows you how to get up and running on Travis-CI and Code Climate for generation unit test coverage with an integration between the two services.

When you maintain an open-source project it is considered a good practice to have a high test coverage, so the community can feel safe about using your code in their projects. There are some services that can analyze your code quality and provide some feedback about it. One of the most popular is Code Climate. This service doesn’t run your tests, but you can use one of CI tools to run them and then send their result to Code Climate. This article will show how to use Travis CI to run your tests and CodeClimate to get your test coverage.

The rest of the tutorial is broken down into five steps (well, five-ish - some have sub-steps):

• Get Your CodeClimate Reporter ID
• Add Your Code Climate Token To Travis CI
• Add CodeClimate Test Reporter Package
• Update phpunit.xml
• Update Travis CI Config To Send A Report

Each section includes the configuration changes to the .travis.yml or phpunit.xml configuration files you'll need to make to connect the services and generate the reports automatically.

For those Phar users out there Théo Fidry has written up a guide to help you create and deploy them securely with the help of a few tools and OpenSSL to sign the release to ensure integrity.

For those who are not familiar with it, PHAR (Php Archive) is analogous to the JAR file concept but for PHP. It allows you to package an application into a single file making it convenient to deploy or distribute.

[...] So what are PHARs useful for then? Well still the same thing: packaging applications. Although not many people may want to use this technique for web applications, it is still extremely useful for console applications.

The tutorial starts off by showing a few different methods for installing Phars and how to build them from your code. While they can be built manually, he suggests using the box project to help make it simpler. It also covers self-updating phars and shows how to update the box.json configuration to use a generated key to sign the release. Finally it covers a method for using Travis-CI to auto-build the phar and how to keep the OpenSSL key safe and out of the checked in code.

If you're a Travis-CI user, like many projects are, you'll find this new post from Raphael Stolt very interesting. In it he provides "eight knobs" you can use to improve your use of the service and optimize your test runs.

After having refactored several Travis CI configuration files over the last weeks, this post will provide eight adjustments or patterns immediately applicable for faster, changeable, and economic builds.

Suggestions in his list include:

• Reduce git clone depth
• Configure PHP versions in an include
• Only do static code analysis or code coverage measurement once
• Run integration tests on very xth build

For each item on the list he includes the updates you'll need to make to your .travis.yml configuration to enable/disable the feature.

In this new post to his site Matthew Weier O'Phinney details the process they (Zend) used to create the documentation for the latest release of their Expressive PSR-7 compatible framework (now in v1.0).

One of the final tasks in prepping for the Expressive 1.0 release was setting up the documentation site. We'd decided to use GitHub Pages for this, and we wanted to automate builds so that as we push to the master branch, documentation is deployed.

The process turned out both simple and bewilderingly difficult. This post is intended to help others in the same situation.

While they decided on MkDocs for the actual document generation (written in Python) Matthew how he integrated it with the builds they'd already created for the Expressive framework. He talks about reusability for the process, eventually using it again on the Zend Framework side. He also shows the full process for creating the resulting documentation and pushing it over to GitHub Pages including the setup of the credentials, which events should trigger the build and handling environment variables and software dependencies. It's a great post with plenty of details on each step of the process - I'd highly recommend it if you're looking into building these sorts of documents for your project.

There's always been an issue with the creation of Phar packages in PHP and the security around them. There's been recommendations about creating signatures and only using secure connections for updates and rollbacks. Unfortunately there isn't an overly easy way to handle this yet. However, Matthew Weier O'Phinney has written up a post showing his workflow for doing these kinds of things, making use of the Box project to help with some of the more detailed parts.

For a variety of reasons, I've been working on a utility that is best distributed via PHAR file. As has been noted by others (archive.is link, due to lack of availability of original site), PHAR distribution, while useful, is not without security concerns, and I decided to investigate how to securely create, distribute, and update PHAR utilities as part of this exercise.

This is an account of my journey, as well as concrete steps you can take to secure your own PHAR downloads.

He starts by outlining the "roadmap" of the features he wants to include and the steps to take to create this more secure phar archive. It includes the use of both current, local tools and services (like Box and GitHub pages). He then walks through the steps in the full process:

• Create an OpenSSL Key
• Use Box to create the PHAR
• Generate a version file
• Create the gh-pages branch
• Write self-update/rollback commands
• Enable Travis-CI for the repository
• Create an SSH deploy key
• Archive and encrypt the secrets
• Write a deployment script
• Add the script to travis

While this seems like a lot of steps to just get a more secure phar set up, Matthew has done the hard work for you here and includes all of the commands, configuration examples and steps you'll need to take to fully set the process up. If all goes well, his example in his last "push and watch it work" section will go off without a hitch.

In this post to his site Matt Stauffer walks you through how he created a custom @requires annotation to use in his PHPUnit testing. He needed a way to tell a test to only run if it wasn't being executed on the Travis CI service.

I was working on a project this weekend that required skipping certain tests in a particular environment (Travis CI). [...] I remembered that there was a @requires annotation in PHPUnit that works natively to allow you to skip a test under a certain version of PHP or with certain extensions disabled, so I set out to write my own custom @requires block.

He links to an article that helped him get most of the functionality in place but decided to restructure it a bit to make the override of the checkRequirements method a bit clearer. He ends up using the Laravel Collection functionality instead of a basic foreach reducing it down to a closure that looks for an environment variable called TRAVIS and automatically mark the test as skipped.

In a post to his site Cees-Jan Kiewiet shows you how to get an authentication token from GitHub to use in your testing on the Travis-CI continuous integration service.

The composer cache greatly speeds up your composer part of the build by only going to Github for new downloads. When combined with test lowest, current, and highest possible on Travis you only reach out to Github for new versions. Most likely to happen during the highest possible set of builds, but also when you've updated composer.*. This normally isn't an issue unless you hit Github's rate limit. And since composer is running on a 'public' travis box with a 'public' IP address that has been use by many builds before it there is a very very high chance it already hit the 60 requests per hour limit.

[...] To counter this problem we have to set a Github authentication token as environment variable in Travis for each project. And update .travis.yml so the token is used by composer.

He walks you through the steps you'll need to get a token of your very own:

• Go to the Settings section on your GitHub account
• Generate a new Personal Access Token
• Add the token to the Travis-CI account you're using for your builds
• Update your .travis.yml configuration with the token information

Each step includes either a screenshot of where to go or the configuration example you'll need to use (like in the yml file).