Garuda解説 #1
まともにブクマしてもらったの初めてだ*1。
というわけで、前回の続き書こうと思います。
動作フェーズ
Plaggerを踏襲しています。
ごちゃごちゃ書くより、Garuda.pmのコード見てもらえれば一目りょう然ですね。
ざっくりと書くと以下のような感じになってます。
- new
- *initialize
- run
- **may_run
- testフェーズ
- **dispatch
- *test.finalize
- filterフェーズ
- *filter.failure
- *filter.result
- publisフェーズ
- *publish.pre_run
- *publish.failure
- *publish.result
- *publish.finalize
「*」がMethod、「**」がHookです。ロードしたプラグインに実装されているアトリビュート付きメソッドがこの順序で実行されていきます。
testフェーズでテストを実行しまくってResultオブジェクトを作り、filterでそれをfilterして、publishフェーズで公開(通知、保存等)ですね。
testフェーズだけ特殊なので後述しますが、その他のhookはアトリビュートを「RuleHook」という拡張hookにすることで、ruleを噛ますことが出来ます。rule機構はPlaggerのをまんまパクったので、実装の仕方も、configの記述方もまったく同じです。
「may_run」は、runすると最初に実行され、falseを返すとすぐにreturnするようになっています。何らかの理由で(targetがメンテナンス中とか)実行して欲しくないときなんかにpluginでその辺のコントロールできるよう入れておきました。G::Plugin::FailOverではこれを使っています。
dispatch
testの実行だけは、単純なhook呼び出しとは異なります。G::P::Test::*な名前空間のpluginは以下のように処理されます。
plugin->config->targetの解釈は、ロードしたTargetモジュールによって異なります。デフォはTarget::Simpleになっているので、単純にリストとして解釈します。その他のTargetモジュールの詳細ついてはpod参照。
たとえば、Target::DBICを使用した場合、$model->searchの第一引数にそのまま渡されます。
- module: Target::DBIC connect_info: - "dbi:SQLite:/path/to/db" - module: Test::Hoge target: hostname: like: 'www%'
は、
$rs = $model->search({hostname =>{like => 'www%'}}, { columns => [$column] }); return [ map { $_->$column } $rs->all ];
となります。columnのデフォはプライマリキーです。
で、その後のフェーズでは、こんな感じで他カラムをhashrefで参照可能なので、テンプレートでごにょごにょしたり出来ます。
$result->failures->[0]->target->info();
DispachプラグインのデフォはDispach::Simpleになっているので、特にロードしない限りはシーケンシャルに実行して行きますが、Dispach::Gearmanを使うと、並列、分散処理が可能になります。testの内容が軽く、Gearman周りのオーバーヘッドの方が気になる場合は、Simpleの方が早い場合もあると思います。
他のフェーズについてはまた後日書く(かもしれない)。
もし、使ってくれて、気になることがありましたらメール(特定のircチャンネルに常駐したりしてないので。。)ください。開発に参加してくれる方も募集しています。
今後はプラグインは増やしていく予定。とりあえずAssurerのを順次移植していこうと思います。
*1:その内の一人が実兄ってのが微妙だが。。