GitHubに置いてるライブラリをTravis CIに対応した
自分のライブラリをTravis CIでテストしてみたメモです。
ほぼ自分専用だし、別に困ってないし…と思って今まで手を付けてなかったんですが、個人ライブラリではユニットテストもそこそこ書くようになってて、 業務でも PHP 5.3系 / 5.4系 プロジェクトが併存している状況になりつつあるので、この機に対応してみました。
単機能的なライブラリばかりなので、対応といってもやることは大してなかったです。
Travis CI への登録
Travis CIへのサインインは GitHubアカウントがあれば即入れます。
入るとGitHubのリポジトリ一覧が表示されるので、Travis CIへのサービスフックを有効にしたいリポジトリのトグルスイッチを「ON」に設定します。
GitHubへのAPIトークンの設定なども、Travis CI側から自動でやってくれます。すごい楽。
以下、 Volcanus_TemplateRenderer の例
PHPUnit用の設定ファイルをリポジトリにつっこむ
PHPUnit用の設定ファイルはすでに書いてましたが、リポジトリには入れてなかったので入れておきました。
<?xml version="1.0" encoding="UTF-8"?> <phpunit backupGlobals="false" backupStaticAttributes="false" bootstrap="Tests/bootstrap.php" colors="true" convertErrorsToExceptions="true" convertNoticesToExceptions="true" convertWarningsToExceptions="true" forceCoversAnnotation="false" processIsolation="false" stopOnError="false" stopOnFailure="false" stopOnIncomplete="false" stopOnSkipped="false" strict="true" verbose="true" > <testsuites> <testsuite name="Volcanus_TemplateRenderer"> <directory suffix="Test.php">Tests</directory> </testsuite> </testsuites> </phpunit>
開発時には Stagehand_TestRunner を使っていて、そっちの設定ファイルもあるんですが、PHPUnitのための設定は上記 phpunit.xml に固めていたので特に書き換える必要はありませんでした。
Travis CI用の設定ファイルをリポジトリにつっこむ
Travis CI用の設定ファイル .travis.yml を新たに作成しました。
.travis.yml
language: php php: - 5.3.3 - 5.3 - 5.4 - 5.5 before_script: - curl -s http://getcomposer.org/installer | php - php composer.phar install --dev --prefer-source script: - phpunit --coverage-text
テストを実施する環境は PHP 5.3.3 と 5.3系の最新、5.4系の最新、5.5系の最新。
composerで依存ライブラリをインストールしてから、phpunitコマンドを実行します。
composer install
コマンドに --dev
オプションを付けてるのは、このライブラリが複数のテンプレートエンジンを共通のインタフェースで利用するためのもので、各テンプレートエンジンへの依存は require-dev としているからです。
(--prefer-source
オプションについては後述)
Composer\Downloader\TransportException 対策
ここまで設定しておけば、GitHubリポジトリへのpush時にTravis CIでテストが実行されるようになります。
早速、.travis.yml と phpunit.xml をリポジトリに追加してGitHubにpushしたのですが、ビルドに失敗したとのメールがきました。
Travis CIの該当ジョブを確認したところ、なぜか PHP 5.3.3 環境だけ composer での Twig のインストール時に以下の例外が発生していました。
[Composer\Downloader\TransportException]
The "http://nodeload.github.com/fabpot/Twig/zip/8873d7593ad7c120004f177c0fd
01459b383c9cb" file could not be downloaded: failed to open stream: Connection timed out
何度か失敗したものの、この問題については前述の .travis.yml にあるように composer install
コマンドに --prefer-source
オプションを付けたら通るようになりました。
http://getcomposer.org/doc/03-cli.md#install
このオプションを付けると、zipファイルからのインストールではなくソースを直接 git clone するようになるようです。
"Composer\Downloader\TransportException" で検索して出てきました、koriym先生のissuesに助けられました。
Composer\Downloader\TransportException in composer install ・ Issue #34 ・ koriym/BEAR.Package
(結局失敗の原因は分からないままですが…。)
ビルド履歴もこんな感じで積み上がっていきます。
コミットログで「travis-ci対応」といいつつビルドに失敗し続けたため、なんだかみっともない履歴が残ってしまいましたが…。
Travis CIの効果
普段はローカル開発環境 Windows PHP 5.4系と会社の開発環境 Linux PHP 5.4系しかテストしてなかったんですが、いくつかのライブラリで 5.3系のみ失敗するものが見つかりました。
($self = $this
でクロージャからプライベートメソッドを呼んでるところがあったのと、テストの書き方の問題で PHP_INT_MAX の値の違いで期待通り動作しないコードがありました。)
あと今回は単機能ライブラリが中心だったため composerによる依存ライブラリのインストールの他は必要なかったんですが、アプリケーションコードのテストの場合、ディレクトリの権限変更など動作環境を準備するためのスクリプトを書かないといけなくなると思います。
今はまだ自動デプロイまでは実現していないのですが、そういったスクリプトを書いておくことが自動化の実現にも繋がるんじゃないでしょうか。
(composerも使えずFTPでアップロードしないと駄目とか、自動化以前のつらい環境もまだまだあるんですけどね…)
GitHub前提のため業務のアプリケーションコードをこれでテストすることはまずありませんが、今年になってようやくPHP 5.2環境を捨て去ることができて、ComposerとDIコンテナ(Pimpleですが…)導入で個人ライブラリをベースに開発することが増えてきているので、今後もTravis CIを積極的に利用しようと思います。