Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Sergey Zhuk:
Test Coverage: Integration Between CodeClimate and Travis CI
Jan 11, 2018 @ 09:42:11

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.

tagged: unittest coverage metric travisci codecliemate integration automatic tutorial

Link: http://sergeyzhuk.me/2018/01/11/travis-with-codeclimate/

Théo Fidry:
Create and deploy secure PHARs
Jan 04, 2018 @ 13:45:57

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.

tagged: phar tutorial install create sign openssl box build travisci

Link: https://medium.com/@tfidry/create-and-deploy-secure-phars-c5572f10b4dd

Raphael Stolt:
Eight knobs to adjust and improve your Travis CI builds
Oct 11, 2016 @ 09:18:53

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.

tagged: travisci service performance improvement build top8

Link: http://raphaelstolt.blogspot.com/2016/10/eight-knobs-to-adjust-and-improve-your.html

Matthew Weier O'Phinney:
Automating GitHub Pages Builds with MkDocs
Feb 01, 2016 @ 10:49:57

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.

tagged: github pages build travisci mkdocs python tutorial process

Link: https://mwop.net/blog/2016-01-29-automating-gh-pages.html

Matthew Weier O'Phinney:
Secure PHAR Automation
Dec 15, 2015 @ 12:32:54

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.

tagged: phar archive security signed https update rollback travisci tutorial

Link: https://mwop.net/blog/2015-12-14-secure-phar-automation.html

Matt Stauffer:
Creating custom @requires annotations for PHPUnit
Oct 28, 2015 @ 10:06:46

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.

tagged: requires annotation custom phpunit travisci skip environment variable closure

Link: https://mattstauffer.co/blog/creating-custom-requires-annotations-for-phpunit

Cees-Jan Kiewiet:
Github auth token on TravisCI
Sep 24, 2015 @ 11:42:01

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).

tagged: github authentication token travisci ratelimit

Link: http://blog.wyrihaximus.net/2015/09/github-auth-token-on-travis/

Lakion Blog:
Easy debugging on CI with Mink
Sep 18, 2015 @ 09:44:12

On the Lakion blog there's a post showing you how to debug your application's Behat tests easily as a part of your continuous integration process. In thieir case, they were trying to figure out why builds were breaking on a Travis-CI build instance.

Debugging Behat scenarios while using Mink to simulate the user is not always an easy job. Especially, if they are run on Continuous Integration server. That is why I came up with an idea to make it easier. During repairing our javascript test suite on Sylius everything went as bad as it could go. There were many errors that happened on Travis, but I was not able to reproduce them locally. [...] MinkDebugExtension was written to speed up that boring and tiring part of debugging on CI server. It consists of two parts: Behat extension and useful scripts.

The extension fires after failed steps and makes a log of the issue with content needed to recreate the issue (including possible screenshots). He also describes the scripts that come with it to help you browse through the results, uploading the resulting logs and screenshots to a place for public consumption.

tagged: mink easy debug travisci continuous integration extension log screenshot

Link: http://lakion.com/blog/mink-debug-extension

Cees-Jan Kiewiet:
Composer cache on Travis
Jul 29, 2015 @ 08:46:52

Cees-Jan Kiewiet has posted an article covering the cache directive on The popular Travis-CI continuous integration service and how it can have an effect on your builds.

Ever since the Test lowest, current, and highest possible on Travis post I wanted to dive into caching composers cache and vendor on Travis. My experiments started the day after that post.

He starts with an example of a simple .travis.yml build configuration that includes the cache directive, showing the caching of entire directories. He points out that, while this can speed up builds, it also comes with a few problems - one being that cache inconsistencies could cause unintended side effects when major changes are made. He points out that most of these risks are worth the gain, though. He's seen a gain of around 40 seconds for a normally 50 second job.

tagged: composer travisci cache configuration caveats

Link: http://blog.wyrihaximus.net/2015/07/composer-cache-on-travis/

Cees-Jan Kiewiet:
Test lowest, current, and highest possible on Travis
Jul 01, 2015 @ 10:57:50

In a new post to his site Cees-Jan Kiewiet talking about "highest" and "lowest" versions of Composer-installed libraries and testing them in Travis-CI builds.

During DPC I've had a talk with Rafael about making sure you test all your possible versions, lowest, current, and highest. The talk was ignited by the infamous composer.lock file (whether to commit it or not).

He goes on to show how you can set up a multiple-version build with the help of the "dependencies" environment variable in your ".travis.yml" configuration file. These are then used in "before_script" commands that tell the Composer install which versions to load. He includes a screenshot of the resulting build and ends with a reminder from Jordi Boggiano (lead developer of Composer) about the resources a build like this takes up and not to do it very often.

tagged: lowest highest library version composer install travisci build

Link: http://blog.wyrihaximus.net/2015/06/test-lowest-current-and-highest-possible-on-travis/