2012/11/05

【解決】GitLabでGit HTTPが使えない問題 (※サブディレクトリ環境)

昨日に引き続き、GitLabの話です。
GitLab 2.7から"Git HTTP"(Git Smart-HTTP)が実装されていたのですが、

いつもはSSH経由で利用しているため、これまでは使っていませんでした。
(※ Git HTTP = HTTP経由でGitLabを通してリポジトリにアクセスする機能)

さて...今日はこのGit HTTP機能をいざ使ってみようと...

GitLab3.0の画面。[SSH]ボタンと並んだ [HTTPS]ボタンをクリックすると
Git HTTPによるURLが表示される。
(URLは、プロジェクトの通常のURLに".git"を付加したものとなる)
表示されたURLをブラウザから開いてみる...と...
回やっても認証画面がwww

正しいメールアドレス+パスワードを入力しているのに
401エラーが出るという・・・(汗;)w

ところで。GitLabでは、サブディレクトリ下での運用を本来サポートしていません。
ですので、私はリバースプロキシ(nginx)を通して少々無理やり運用しています。
(それについては、記事:Gitlabの導入 (Unicorn+nginxでサブディレクトリへ配置)を参照)

今回は恐らく、そのための問題なのだろう...と仮定して調べてみました。
(他の可能性としては、gitlab.ymlの設定ミスもありますが、今回は問題ありませんでした。)

→ 結果...その通り!やはりサブディレクトリ下で運用していることが問題なようですorz

とりあえず...手探りで試行錯誤してみましたので、
対策方法を以下に残しておきます。

[注意] GitLabのサブディレクトリでの運用が本来サポート外であるうえに、
私はいまのところ Ruby/Unicornに全く詳しくありませんww
そのため保障はできませんが、参考にまで。
...もっと良い方法があればアドバイスお願いします m(_ _)m )





/gitlab/lib/gitlab/backend/grack_auth.rb : 17行目付近〜

@env['PATH_INFO'] = @request.path
@env['SCRIPT_NAME'] = ""

# Find project by PATH_INFO from env
#if m = /^\/([\w-]+).git/.match(@request.path_info).to_a #コメントアウト
if m = /^(\/([\w-]+))*?\.git/.match(@request.path_info).to_a
    self.project = Project.find_by_path(m.last)
    if m2 = /\/([\w-]+*?.git\/.*)/.match(@request.path).to_a
        @env['PATH_INFO'] = "/#{m2.last}"
    end
    return false unless project
end

変更点としてはこれくらいです。



以下に、何を行ったかの解説&メモを書いておきます。

まずGitLabでは、Grackというモジュールを用いることで
このGit HTTPを実現しているようです。
GitLabのルーター(/gitlab/config/routes.rb)はユーザからアクセスを受けると、
Git HTTPのためのアクセスをここで受け取ります。

Grackの認証(Basic認証)には、GitLab上のアカウント情報が用いられます。
実際にその処理を行なっているのは/gitlab/backend/grack_auth.rb ですね。


上のgrack_auth.rbでコメントアウトした行とその次行の
# if m = /^\/([\w-]+).git/.match(@request.path_info).to_a
    self.project = Project.find_by_path(m.last)
はリクエストされたパス(@request.path_info)からプロジェクト名を抜き出しています。
本来、パスが"/hoge.git/aaaa"だとしたら、
hogeという部分が正規表現で抜き出され、self.projectに代入されるわけです。

ただ当然これでは、パスがサブディレクトリを含んでいると正しく抜き出せないですね。

ですので...コメントアウトした行の代わりにこのように追加しました:
if m = /^(\/([\w-]+))*?\.git/.match(@request.path_info).to_a

これにより、サブディレクトリであっても正しくプロジェクト名が抜き出せます。

さて...この修正だけで、事態(?)には光が見えてきます(笑)w
プロジェクト名が正しく抜き出せなかったために、
プロジェクトを探せず、401エラーになっていたようです。

これでとりあえず、401エラーが改善し、認証は正常に通るようになります。

が...。

ここでまだ、git cloneしてもうまく行かないはず・・・。

Grackの認証が済むと...
プロジェクト名やパスを環境変数(@env)で渡して次の処理を
/gitlab/vendor/bundle/ruby/*.*.*/bundler/gems/grack-*/lib/grack/*.rb
が行うわけですが・・・。

ここでリポジトリ上のファイルを読み込む時・・・
サブディレクトリのせいでパスを正常に扱えず、ファイルが見つからないのですw
なのでエラーとなります。

この対策のために、前のステップでパスを直しておくことにしました。
先ほどとおなじくgrack_auth.rbでやってしまいましょうw

以上の理由から、先ほどの行の後に2行追加しました:

        if m2 = /\/([\w-]+*?.git\/.*)/.match(@request.path).to_a
                @env['PATH_INFO'] = "/#{m2.last}"

正規表現マッチもあれな書き方ですが、未だ詳しくないので許してください(><;)

これににより、環境変数に入れるパスからサブディレクトリ部分が削られます。
つまり、本来、GitLabが意図しているパスになるわけです(>ω<)♪

これで一応、解決です。

試しに...クライアントから
$ git clone https://example.com/git/hoge.git
を実行してみてください。正しくcloneできるはずです。

今回は以上となります。

今回もこのヒントを得るためにGitHubやコミュニティを参考にさせていただきました。
ありがとうございました m(_ _)m♪


p.s.

そもそもサブディレクトリじゃなくルートでGitLabを運用したらいいのに...
と思われる方もいらっしゃるかもしれません・・・。

私は学生個人でサーバを運用しています。
そしてこういったものに、HTTPSは必須だと考えております。
ところで、ルートディでGitLabを運用するには、当然、サブドメインなり別サーバ/IPアドレスなりの方法を取らなければなりませんが、
それをするとなると、サーバ証明書もGitLab用に別途用意することになります・・・。
サブドメインでも使える証明書は高価ですし・・・。
そこまでの余裕は無いのです(´・ω・`)...。

尚、GitLabはサブディレクトリへの対応を実装することは今のところないそうです。


2012/11/04

GitLab 2.8→3.0にバージョンアップ

前回の記事(Gitlab 2.7 → 2.8にバージョンアップ)から約2ヶ月...
9月末にGitLab 2.9が公開されていたんですが...
つい先月(10月)末に、GitLab 3.0が公開されたようです。
http://blog.gitlabhq.com/gitlab-3-dot-0-released/

とりあえず変更点を...(適当に翻訳しましたw)

2.9での変更点は以下の通り (公式ブログより抄訳)
  • 400コミット以上の素晴らしいコード
  • コメントの表示順を変更 (Wallを除く)
  • omniauthのサポート (twitter, google…)
  • Bunch of stuff の修正 (訳注: たくさんのモノ/諸々 とでも訳しておきますかw)
  • 多くのコードのリファクタリング
  • Gitolite v3への対応
  • 絵文字機能
  • LDAPとOAuth設定を一つに集約 -> config/gitlab.yml
  • ProfileとAdmin画面に新機能
  • 多くのAPIを追加

そして 3.0での変更点は以下の通り (こちらも公式ブログより抄訳)
  • 300コミット以上の素晴らしいコード
  • ウェブエディタ機能
  • より多くのAPIを追加
  • ファイルブラウザの改善
  • SSH鍵の追加と削除についての致命的な不具合修正
  • (非公式な) Postgreサポート
  • プロジェクトグループ機能
  • ファイルとコミットについてのパフォーマンスがかなーり改善
  • コードのリファクタリングとクリーンアップ など...
うーん。これは楽しみ!!
ということで、3.0へのバージョンアップを行いたいと思います(>ω<)

私の場合、2.9→3.0ではなく2.8→3.0のバージョンアップとなるため・・・
こちらのドキュメントを参考にしたいと思います:

https://github.com/gitlabhq/gitlabhq/wiki/From-2.6-to-3.0
(そうじゃなくてすでに2.9をお使いの方はこちらを参照)

毎度のことですが、更新はgit pullして取得できて楽ですね。
今回はそれに加えて、hooks(post-receive)の上書きと、
gitlab.ymlの再設定が必要になりました。
必要に応じて、バージョンアップ前にバックアップをとっておくといいかもしれません。
(さらに私の環境では、サブディレクトリで動作させる等々しているので殆ど前回同様に再設定が必要でした。)


GitLab 3.0にバージョンアップ完了

それにしてもGitLab、友人と一緒の開発に使っていますが...使いやすいですね。
(元々のアイデアであるGitHubもそうですけれど)
他のプロジェクト管理システムよりも色んなモノを削って、またGitに特化している分、
使いやすさがあるんだろうな〜と思います。

GitLab 2.9から追加された Issueでの+1 機能。
コメントを書く時、"+1"という文字を入れておくと、カウントしてくれます。
こういう機能も他のプロジェクト管理システムだとプラグインで使えたりしますが、
標準で実装されるのはちょっと嬉しいですねw
(尚、軽めにぼかし入れてますが、開発中のモノです。見えてもいいんですけど一応軽くw )
Trac,Redmine,etc...を使っていると、
欲を言えば、GitLabはモノ足りないかなーと思うことが無いこともないんですけど、
それでも...必要十分以上の機能は揃っているわけです。
毎日のように使うツールですから、”シンプル”であることは大切だと思います。
開発メンバーが増えたときの慣れやすさを考えてもそうですしね。




2012/10/30

Perl/Wx - Wx::Demo サンプルGUIアプリケーションを試そう

昨日(Perl/Wxをはじめてみよう (PerlでGUIアプリケーション))に引き続き、
PerlとWx(WxWidgets)でGUIアプリケーションを作るという話題です。

今回はCPANで公開されているデモアプリケーション(Wx::Demo)を試してみます。
サンプルプログラムとソースコードをインストールできるモジュールになっていて、
インストールするだけ、とっても簡単に試せます。

利用する環境は昨日の記事とおなじく、Linux(Fedora 17)+ perl-5.14.2 です。
すでにwxWidgetsとWxモジュールもインストール済みとなっています。



まずはWx::Demoをビルドしてインストールします。
http://search.cpan.org/~mdootson/Wx-Demo-0.19/lib/Wx/Demo.pm
執筆時点の最新版は、Wx-Demo-0.19となっています。
アーカイブファイルを適当なディレクトリに展開して、いつもどおりビルドします:

$ wget http://search.cpan.org/CPAN/authors/id/M/MD/MDOOTSON/Wx-Demo-0.19.tar.gz
$ tar zvxf Wx-Demo-0.19.tar.gz
$ cd Wx-Demo-0.19/
$ perl Makefile.PL
$ make
$ make test
$ sudo make install

これでWx::Demoのインストールは完了です♪

あとは実行するだけ:

$ wxperl\_demo.pl

これでこのようなウィンドウが表示されます。



左側のペイン("Categories"タブなど)に、サンプル一覧がツリー表示されます。
これを選択すると、右側のペインにこの画像のようにサンプルが表示され、
さらにSourceタブから該当ソースコードも閲覧できる仕組みになっています。

ちなみに、このWx::DemoをMacやWindowsなど他の環境で実行すると...
それぞれの環境に用意されたネイティブGUIを使って、違和感なく表示されます。
これは"ネイティブGUIへのラッパーを基本としているwxWidgetsの強み"でもあります。
(また、その環境のネイティブGUI上に該当するパーツが存在しない場合には、wxWidgetsによって再現された共通的なパーツで代替する仕組みになっています。)

今日はここまで(>ω<)♪


2012/10/29

Perl/Wx(wxPerl)をはじめてみよう (PerlでGUIアプリケーション)

Perl/Wxをはじめてみよう...ということで。
WxWidgets(クロスプラットフォーム対応のGUIライブラリ)で
超シンプルなGUIアプリケーションを作りますw とっても簡単です。


まず、wxWidgetsというのは、
Windows / Mac / Linux(GTK)のネイティブGUIを利用できるラッパーライブラリです。

PerlのCPANで公開されているWxモジュール(WxPerl)は、
このWxWidgetsをPerlから利用するためのモジュールです。
最新版は、0.9914 (2012年10月02日)、かなり最近です。
これに関して、Perlでこの話題を持ちだしてきたのにはちょっと理由があるのですが、それは最後にでも(笑)

余談ですが、かの "Google Drive"のPC向けアプリケーションも
wxWidgets(wxPython)で開発されているようです (→公式サイトのNews
参照)
様々なアプリケーションに利用されているライブラリであることは何より安心できますね(>ω<)♪



さて今回は、Linux(Fedora 17)環境で wxWidgets 2.9.4による
GUI(GTK+2)アプリケーションを作ってみたいと思います。

(尚、WindowsやMacにおいても、書くべきソースコードは共通となります。
WxWidgetsとWxモジュールのインストールが少々異なってきますが、参考にしてください。)

perlの環境がインストールされていることが前提です。
(私のFedora環境では、perl-5.14.2を利用しています。)

まず、GTK+2の開発パッケージをインストールします。
$ sudo yum install gtk2-devel

次に、Alien::wxWidgetsモジュールをビルドしてインストールします。
(今回はCPANでうまくインストールできなかった為、自前でtar.gzをダウンロードしビルドしました。)
http://search.cpan.org/~mdootson/Alien-wxWidgets-0.62/lib/Alien/wxWidgets.pm
このモジュールは、ビルド時に適切なWxWidgetsを取得してビルドしてくれます。

$ wget http://search.cpan.org/CPAN/authors/id/M/MD/MDOOTSON/Alien-wxWidgets-0.62.tar.gz
$ tar zxvf Alien-wxWidgets-0.62.tar.gz
$ cd Alien-wxWidgets-0.62/
$ perl Build.PL
〜ここで以下のような質問が表示されますが適当に答えて... 2.9.4 (執筆時点のLatest Development版) をインストールしてもらいますw〜 Which wxWidgets version? (2.8.10, 〜 , 2.9.4) [***] 2.9.4
Which archive type? [tar.bz2 ] (そのままEnter)
Do you want to include OpenGL support [no ] (そのままEnter)

$ perl Build
$ perl Build test
$ sudo perl Build install
$ sudo ldconfig

次に、Wxモジュールをビルドしてインストールします。http://search.cpan.org/~mdootson/Wx/Wx.pm

$ wget http://search.cpan.org/CPAN/authors/id/M/MD/MDOOTSON/Wx-0.9914.tar.gz
$ tar zxvf Wx-0.9914.tar.gz
$ cd Wx-0.9914/
$ perl Makefile.PL
$ make
$ make install
(後述のようにユーザディレクトリ下にPerl環境を置いている場合は、sudoをつけないほうが良さそうです。
もちろん、システムでPerl環境を共有している場合には、sudoをつけてmake installしてください。)

これで準備完了です。

あとは... ソースコードを書くだけです。
use Wx;

my $app = Wx::SimpleApp->new;
my $frame = Wx::Frame->new( undef, -1, 'Hello, world!' );

$frame->Show;
$app->MainLoop;

(http://search.cpan.org/~mdootson/Wx/Wx.pm より引用)

これを適当に保存して、実行してみましょう。
$ perl hoge.pl

こんなウィンドウが表示されたら成功です(>ω<)♪



この時、もしも...次のようなエラーが表示されたら...
Can't load '/***/Wx/Wx.so' for module Wx: libwx_gtk2u_adv-2.9.so.4: 共有オブジェクトファイルを開けません: そのようなファイルやディレクトリはありません at /***/DynaLoader.pm ***.
この場合はライブラリが認識されていません。

どうやらperlの環境によっては、ライブラリファイルがユーザディレクトリ内にインストールされてしまい、その結果として認識されないことがあるようです。
(Alien::WxWidgetsのビルド時にBuild.PL --prefix=***を指定しても効きませんでした・・・
調査中です。どなたか正しい方法をご存知でしたらアドバイスをお願いいたします m(_ _)m
Perlbrewの環境とかもそうなったりするんでしょうか・・・未確認です。)


(あんまり良い方法では無い気がしますが...)とりあえず対策として
ライブラリパスをユーザの環境変数に追加しておきます。

まずは目的のライブラリファイルを探します...
$ sudo find / -name "libwx_gtk2u_adv-2.9.so.4"

ファイルは見つかりましたか?
(例: /home/hoge/perl5/lib/perl5/x86_64-linux-thread-multi/Alien/wxWidgets/gtk_2_9_4_uni/lib/libwx_gtk2u_adv-2.9.so.4 )

見つかったファイルのあるディレクトリを登録します:
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:***/Alien/wxWidgets/gtk_2_9_4_uni/lib/ (上の例であれば...ディレクトリは、/home/hoge/perl5/lib/perl5/x86_64-linux-thread-multi/Alien/wxWidgets/gtk_2_9_4_uni/lib/)

さらに、同じexport文を ~/.bashrc の末尾にも追加しておきます:
$ vi ~/.bashrc

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:***/Alien/wxWidgets/gtk_2_9_4_uni/lib/

その後、もう一度、sample.plを実行してみてください。今度は動くはずです(汗;)
$ perl sample.pl


さて...今回はこのへんで。
大学のテストが間近なのでテスト勉強してきますっ(`・ω・´)シャキーン (汗;) (

デモアプリケーションがCPANでWx::Demoとして公開されているので
そちらを参考にしつつ使わせてもらいましょう(>ω<)♪


[2013/06/23 追記]
Arch Linux(64bit), perl-5.18.0の環境で試してみたところ...
$ cpan Alien::wxWidgets Wx
とCPANシェルでインストールするだけで、wxPerl環境の構築が楽にできました。
上記のサンプルコードもそのまま動作しました。何か作ってみようかな♪

また、直接関係ありませんが、wxWidgetsのドキュメント日本語訳プロジェクトが新たに始動されていました。
日本でもwx関連がまた活発になっていくといいですね。


[余談]

この記事を突然書くことにしたのには経緯があったりします。
実は以前から私はWxWidgetsとWxモジュール(WxPerl)をかじっていた時期がありました。
ただ、2010年になってからしばらく...モジュールのアップデートが特になくなり...。
私も、Web開発のほうに興味が傾いていた事もあって、GUIアプリ開発そのものが少なくなり、
その後はたまにWxPerlのウェブサイトをのぞいたり...といった程度になっていました・・・。

そんななかで先日、2012年になって再びアップデートが積極的に行われていることを知りました。
何より嬉しくなったのと、最近流行り(?)のWebアプリケーションでなく、
Linuxでも使えるスタンドアロンなGUIアプリケーションを作りたいな〜と考えていたことから
ちょっと記事に起こしてみることにしましたw

おっとww 余談が長くなってすみませんでした(^^;)ゞ

2012/10/07

[構想] 大学のA3プリント類を便利にスキャンするために

大学の夏休みもあけ、もうそろそろ稲刈りの時期ですね。
・・・というわけで(?)、大学のプリント類も少々溜まって来ました。
ScanSnapで整理しないとw と思っている今日このごろのMasanoriです。

以前から、ScanSnap S510を(旧)自宅サーバPCに接続しておいて、
プリント類をスキャンしてはGoogle Drive(Google Docs)に自動アップロード
...ということは行なっていました。家族共有もできますし、なかなか便利です。

ところで...。
うちの大学のプリントは、A3サイズで両面印刷が多いのです。

ScanSnapでは、
A4サイズの場合は、自動給紙で両面&複数枚を取り込めます。便利です。

しかし、A3サイズの場合は、2つ折りにして(物理的にA4サイズにして)、
”A3キャリアシート”というシートで挟み込んでからスキャンしなければなりません。
つまり、両面取り込むには、A3キャリアシートから一旦取り出して、裏返して、2つ折にして、再度挟み込んでからスキャンしなければなりません。

まあそれは、そもそも物理的にそういう仕様ですから仕方ないですね(^^;)ゞ

で・・・続きなんですが。
A4サイズの場合は、連続給紙した分をすべて1つのPDFファイルに仕上げてくれます。
しかし、A3キャリアシートを使っている場合はそうはいかず、別ファイルになってしまいます。
(※ScanSnapの付属ソフトウェアにある"継続読み取り機能"を使えば、解決できます。)
なので、私は、必要に応じて、できあがったPDFファイルをサーバPCから取ってきて、
手元のPCで、PDFを結合するなど処理を加えて、再度保存...ということをやっていますww

付属ソフトウェアにある"継続読み取り機能"を使えば実現できるんですけど、いちいち指定するのめんどくさい!
というか、サーバPCに接続しているんで、ディスプレイレスなんですww

私としては、本体のスキャンボタンを押すだけで、PCに触れることなく一連の操作を終わらせたい...という願望(?)がありますw

というわけで前置きが長くなりましたが、やりたいこと:
  • ScanSnap本体のスキャンボタンを押すだけで自動的にスキャンして、
    OCR処理をして、Google Driveに自動アップロード。
  • ScanSnapを接続するPCは、一切操作しなくていい。
  • ScanSnapを接続するPCは、Windowsじゃなく、Linux
  • A3キャリアシートを使っている場合も、一定時間内に複数枚スキャンすれば、
    それらを一つのPDFファイルにまとめてくれる。
以上です。Perlでごりごりやろうかな。

p.s.

このブログのデザインを変更しました。
...といっても背景画像は、about.meや他のサイトでも使っているものなんですが。
Androidファンなのでw ドロイドくんを使わせていただいています(><)♪

2012/09/12

Gitlab 2.7 → 2.8にバージョンアップ

友人との開発プロジェクトにGitLabを実際に利用させていただいています。
GitHubに使い勝手が近いこと、また、RedmineやTracほど大規模でないため
とても手軽で、メンバーの学習コスト的にも敷居が低く、最適だと思っています。
(前回の記事: Gitlabの導入 (Unicorn+nginxでサブディレクトリへ配置))

さて今回は、8月末にGitLab 2.8が公開されたため、
現在のGitLab 2.7からバージョンアップをすることとしました。

GITLAB 2.8 released - GITLAB Blog

Gitlab Flavored Markdownなどなど...便利になりますね。
(プレビュー機能が使えて、その場で確認もできるようになりました。)
また、詳細まで追ってはいませんが、Security fixもあるそうですから
アップデートしておいたほうが良いと思います。

アップデート手順のドキュメントが公開されており、基本的にはこのとおりです。
https://github.com/gitlabhq/gitlabhq/wiki/From-2.7-to-2.8
(推奨OSではなく、CentOS 6.2上で動作させていますが、特にこのとおりで問題ありません。))

GitLabのディレクトリでGitを使ってgit pullしてきて、
bundleコマンドをいくらか実行するだけなので、楽ちんですね♪



以下は、どちらかといえば私のサーバ環境固有の問題なのですが... (一応メモですw)

1. Gitoliteのユーザアカウントに対してホームフォルダを作っていないためそのままでは動作しませんでした(詳しくは前回の記事を参照)
→ egrepコマンドで"/home/git/"ディレクトリのパスが決め打ちされている箇所を探して書き換えることで対処できました。

2. nginx+Unicornでサブディレクトリ下でGitlabを動作させるため
コードをほんの一部書き換えているのですが、git pullする際に
マージするか、一旦上書きしてしまって再設定する必要がありました。


3. Gitlab2.8以降のGitlab Markdownによってリンクタグ生成処理が変更されており、
Markdown記述内のリンクには、サブディレクトリが含まれませんでした。
(<a href="http://example.com/gitlab/hoge/issues/1">〜〜</a> になってほしいところが<a href="http://example.com/hoge/issues/1">〜〜</a> になるという。)

→こちらは追加の変更で対処できました: (下線の箇所にサブディレクトリパスを記述)

/lib/gitlab/markdown.rb: 147行:
link_to("##{identifier}", 'gitlab/'+ project_issue_path(@project, issue), html_options.merge(title: "Issue: #{issue.title}", class: "gfm gfm-issue #{html_options[:class]}")) 
同じ感じで...153行、159行、165行目にもパスを追加していきます。

以上です。

GitLabのサブディレクトリの件、もし不具合なのであれば、
GitHubで報告したいのですが、以前からサブディレクトリ対応については
ドキュメントでも触れられていませんし・・・仕様なのかなと。
もし宜しければ、どなたかお願いしますm(_ _)m

2012/08/10

Travis CIでPerl(Mojolicious)アプリケーションを自動テスト


Perl+Mojoliciousで作成しているWebアプリケーションがあるのですが、
折角、GitHub上でオープンソースとしてリポジトリを公開しているのだから
Travis CI自動テスト(継続的インテグレーション)をしてもらわない手はないっ!
...ということでテストしてもらうことにしました。

この記事はMojolicious(Test::Mojo)でテストスクリプトを作成していること前提です。

まずは、http://travis-ci.org/ からGitHubアカウントの認証を行います。

認証できたら、Travis CIのプロフィールページへアクセスして
[Token]の文字列を確認しておきます。


次に、GitHubへアクセスして・・・
テスト対象とするリポジトリの[Admin]ページから、[ServiceHook]ページを表示。


AVAILABLE SERVICE HOOKSのリストから、[Travis]を選択します。

すると入力フォームが表示されるので、Token欄にさきほどのTokenを入力して
[Active]にチェックを入れたら、[Update Settings]ボタンをクリック。
さらに、[TestHook]ボタンをクリックします。





次に、Travis CIのプロフィールページへ再度アクセスし
[Repos]タブをクリックすると、自分のリポジトリ一覧が表示されるので、
テスト対象とするリポジトリ名の横にあるスイッチを[ON]にしておきます。



次に、Gitリポジトリのルートへ、".travis.yml"というファイルを作成します。
こんな感じでテストのための環境を定義しておきます。
$ vi .travis.yml 
language: perl
perl:
  - "5.16"
  - "5.14"
install:
    - cpanm --installdeps --notest .
script: "perl Makefile.PL && make test"
(2013/08/18 更新、2014/04/22 更新: mirrorの指定が不要になっていました。)

  • perl項目: テストしたいperlのバージョン
  • install項目: テスト & インストールのためのコマンド
    ここでは必要なモジュールをcpanmでインストールするよう指定しています。
    (さらに詳しいログが必要ならば、 cpanm -v 〜 のようにオプションを付ける。)

詳しくは、http://about.travis-ci.org/docs/user/languages/perl/ 参照のこと。

さらに、MojoのコマンドでMakefile.PLを作ります。
$ mojo generate makefile
Makefile.PLが作成されているので
これをテキストエディタで開き、必要に応じて修正を行います。

具体的には、テストの前にインストールが必要ないわゆる依存モジュールを
PREREQ_PMに定義しておきます。
$ vi Makefile.PL 
use strict;
use warnings;
use ExtUtils::MakeMaker;

WriteMakefile(
  VERSION   => '0.01',
  test      => {TESTS => 't/*.t'},
  PREREQ_PM => {
  'Mojolicious' => '3.20',
   'Validator::Custom' => 0,
   'Config::Pit'   => 0,
   'DateTime'    => 0,
   'JSON'     => 0,
   'String::Trigram'  => 0,
   'Data::Model'   => 0
  }
);

今回のアプリケーションの場合、このようになりました。

最後に、GitHubへプッシュ。
$ git push
これでしばらくすると...

Travis CIのトップ画面の一覧に自分のプロジェクトが表示されますww (おぉ〜!)


また、自分のプロジェクトのテスト結果ページができています。
http://travis-ci.org/#!/mugifly/Fsq2mixi



ここで緑色で表示されていれば、無事テストをパスしたことになります。
赤なら...詳細を見てエラーの原因を調べましょう...ということのようです。

後はプッシュするたびに自動テストを行なってもらえるようです。

さてさて...テストの中身をもっときちんと書かねば(^^;)ゞ
(実は今回お題にあげたプロジェクトはテストを思いっきりサボ(げふんげふん)




参考にさせていただいたページ (感謝♪):