r-labs » Hudson

ビルドの履歴をDBに持つのは、Hudsonの流儀に反しそう？でちょっと気が引けます。

活動ページに表示している様々な履歴を管理する方法を知らないので、
そこを知ることから始めますね。

活動ページに出すためにはDBへの格納が必要だと思います。

活動の1レコードはacts_as_activity_providerを実装したActiveRecordのモデルです。

なのでやるならやはり履歴情報をDBに取り込むしかないと思います。

Redmine.org に出したら、そこでも要望が。
意外と多いのかもしれませんね。

もう少し様子見して、多そうなら考えます。（多分リポジトリの履歴と同じはず？）

リポジトリの履歴はどうなっているんだろう？と思って、DB見てみたら…
なんと！ ファイル1つ1つの状態まで全部保存しているんですね。こりゃぁスゴイ。

うちのプロジェクトも長いけど、件数どのくらいになっているんだろう…。

履歴のサマリとして何を保存するのかよく判りませんが、1レコード平均100バイト程度だとすると1万件でやっと1Mバイト程度なのでデータ容量についてはあまり心配しなくてもよいのではないでしょうか。

サマリに何を登録しようか？というのは考えてなかったです。
Jens Goldhammer さんいわく、

Maybe you can only insert summaries of the last 30 minutes. 
"Last build successfull (7 builds failed before) of hudson job xy".

だそうです。ジョブ1つ1つの結果を要約して登録って感じですね。
ちなみに件数ですが、

• 10個のジョブが、1日2回動作すると考えると、1日20個の履歴。
• 1ヶ月=20日として考えると、20*20=400件
• 1年=12ヶ月だから、400*12=4800件

…たいしたことないですね。1日5回動作しても、20,000件行かないし。
うーん。やってみるかな。

ジョブ、ビルド、チェンジセットの情報を蓄積することにする。
上記の情報は現在ハッシュで管理しているので、これを全部クラス化…。
とりあえずは終了。

最初からクラスにしておくのがいいのかなー。Rubyの場合そうコストは高くないし。

あるビルド番号以降のデータを取得する方法が不明…。
XPATH はあっていると思うのだけど。

仕方ないので rssAll で取れる分だけとることにした。
初回取得時(ものすごく時間がかかる)と、更新時のパターンを分けないといけない感じ。

あー。面倒。

ついでなので、Changeset や Artifact も保存できるようにしよう。
で、備忘録。

• 今まさにビルド中であったものについて

は、後からビルドの情報を再取得しないといけない。
あぁ。やること多いなぁ。

ひとまずChangesetまで保存できるようになったけど、
かなりエラー処理しっかりしとかないと、すぐ整合性が崩れそうだ…。

Repositoryまでとは言わないけど、かなり大変なことに手を出した気がするぞ…。

一旦整理のために、処理の流れをかいてみる。

index の表示処理¶

おおまかに分けて以下の処理がある。

1. DBからジョブの情報を取得する
2. ジョブの情報を更新する
3. ビルドの情報を更新する

DBからジョブの情報を取得する¶

1. ジョブの情報を取り出す。
2. 最新のビルド情報を取り出す。 ここでやるべき処理ではない

ジョブの情報を更新する¶

1. HudsonAPIをノックして、ジョブの一覧と最新ビルドを取得
2. ビルドの情報がDBにない場合は新規に登録する
3. ヘルスレポートを取得する ここでやるべき処理ではない

ビルドの情報を取得する¶

1. rssLatestを使って各ジョブの最新ビルド情報を取得する
2. DBの最新ビルド番号と異なる場合に、以下の処理を行う
   1. HudsonAPI(各ジョブのrssAll)をノックして、ビルド情報を取得する
      本来はDBの最新ビルド番号以降から、現時点での最新ビルド番号までとしたいのだけど、方法が分からない。
   2. DBに保存していないビルドの場合に、以下の処理を行う
      1. HudsonAPI(各ジョブのrssAll)をノックして、チェンジセットの情報を取得する
      2. ビルドとチェンジセットの情報を保存する
3. 最後にジョブの最新ビルド番号を更新する

さて、今回はどのへんで整合性が必要となるか？

1. DBに登録されているジョブの最新ビルド番号と、ビルドの情報
2. ビルドの情報とチェンジセットの情報

これくらい？

• チェンジセットの情報を取得できなかったら、ビルド情報は保存しない。
• 最新のビルド情報を取得中に、1件でもエラーが発生したら、ビルド情報は取得できなかったとする
• ビルド情報を取得中に、エラーが発生したら、最新のビルド情報は更新しない

2つ目のルールはちょっと厳しいなぁ。途中が抜けるのはいやなので、

• チェンジセットの情報を取得できなかったら、ビルド情報が取得できなかったことにする。
• 最新のビルド情報を取得中に、1件でもエラーが発生したら、成功した分を保存する
• ビルド情報を取得中に、エラーが発生したら、成功したビルドの中で最新のビルド情報を保存する

かなぁ。エラーの情報はどう扱おうか。

ふと思ったけど、Hudson の不具合でジョブの情報が取れない場合もあるので、
エラーが発生したビルドのコトはとりあえず置いとく。というスタンスを取ろう

• ビルド情報を取得中にエラーが発生しても、とりあえず全てのビルドの情報を取得する
  • エラーの内容によって、ビルド情報を取得するべきか、そうでないのか判断したほうがよさそうだ
• チェンジセットの情報を取得できなかった場合でも、とりあえずビルド情報は保存する
  • エラーが発生した旨を登録できればいいだろう。
• ジョブの最新ビルド番号は、取得に成功したビルド情報の中で、一番新しいものにする

とは言え、エラーが発生したビルドを放っておくのもかわいそうだし、
どうやってリカバリーしたものか。リトライを手動でできるようにしておくかな？
ということは、取得したビルド情報を見れたほうがいいってことだよなぁ…。

エラー時のリカバリは取りあえず放っておけばいいんじゃないでしょうか。

まずはシンプルに作って後から機能を追加していってしまえば。

なんとなく、RSSは取れるけど詳細は取れないっていうケースはまず起こらないんじゃないかと。多分どちらも元ネタは同じだと思うので。

RSSが取れなかったら多分次回アクセス時に勝手に取れなかったところ以後を取りにいくことになるんですよね？

Haru Iida wrote:

エラー時のリカバリは取りあえず放っておけばいいんじゃないでしょうか。
まずはシンプルに作って後から機能を追加していってしまえば。

なるほど。
Redmine だけの問題じゃなくなるので、エラー周りはある程度ユーザに親切にしておきたいなぁ
と思っているのです。はい。
が、あんまり長いこと放置状態もよくないので、そろそろかなぁ。

なんとなく、RSSは取れるけど詳細は取れないっていうケースはまず起こらないんじゃないかと。多分どちらも元ネタは同じだと思うので。

実はあったりするんですよ。Changeset まで含めると。

RSSが取れなかったら多分次回アクセス時に勝手に取れなかったところ以後を取りにいくことになるんですよね？

これは結構悩みどころで、エラーコードによるのかなぁと思っていたり。
500 系は取りに行く価値があるけれど、400系ってもう一度取りに行って成功する確率あるのかな？と。
もしかすると、

• エラーがおきたことは分かるようにしておいて、自動では取りに行かない

が正解かもしれません。

とりあえずビルド情報までを保存できるようにして、活動履歴を出してみます。

activity_provider/acts_as_event/acts_as_activity_provider

を解説しているところはないですよね…。

CodeReview をまねしたつもりだけど Activity のサイドメニューにすら出ない…。

init.rb に activity_provider を追加¶

  activity_provider :hudson, :class_name => 'HudsonBuild', :default => false

対象のクラス(HudsonBuild)に、acts_as_event, acts_as_activity_provider を追加¶

  acts_as_event :title => Proc.new {|o| "#{l(:label_build)} #{o.job.name}-#{o.number}"},
                :description => '',
                :datetime => :finished_at,
                :url => Proc.new {|o| o.url}

  acts_as_activity_provider :type => 'hudson',
                             :timestamp => "#{HudsonBuild.table_name}.finished_at",
                             :find_options => {:include => [:job]}

Auther はいないので、指定していないんだけどこれがダメ？ でも何を指定しろと…orz

解決。はまったことは [[プラグイン_Tips]] に記載するようにします。

う。そういえばテスト結果を全然表示できてないや…。

詳しい情報を取得する。

詳細な情報は http://{$HudsonURL}/job/{$JobName}/api/xml?depth=1 から取得する。

取得できる件数は、 http://{$HudsonURL}/job/{$JobName}/rssAll で取得できる件数と同じ¶

ビルド中のものがあった場合は、1件多くなるかもしれない。

変更(Changesets)が取得できる¶

変更した人／日時／リビジョン番号／コミットメッセージ／あれこれ
でも、チェンジセットは Repository モジュールが管理してくれているから、番号だけあれば十分。

テストの結果が取得できる¶

トータルの件数／失敗した件数／スキップした件数(って何だろう？)

成果物が取得できる¶

表示名／ファイル名／ダウンロードする際のURL
成果物はファイルだったりフォルダだったり、ビルドの設定によって異なる。
フォルダの場合？は、表示名やファイル名がないっぽいので、その辺を判断材料にするか。

使い道¶

さすがに詳細なだけあって、大きなビルドだと返事がかえってくるまでに時間がかかる。
なので、

• rssAll で情報を取得して、更新しないといけない場合にのみ、 api を呼び出す

ほうがストレスが溜まりにくそう。
とりあえず、テスト結果の取得から。

テスト結果と変更が保存、活動の履歴に表示できるようにしました。
今まで取得したテスト結果と変更を取得するには、履歴を全て消す必要があります。
設定画面の「履歴を削除」ボタンをクリックすると履歴が全て消えるので、
その後 Hudson タブにアクセスしてください。

ビルドの情報を更新するタイミングは、Hudsonタブにアクセスしたとき。
複数の人が同時にアクセスするとなんだかやばそうな気がする。
どうやって排他制御しようか。

大きなプロジェクトのビルドだったり、Hudsonがインストールされている端末が非力な場合は
ビルドの詳細（変更やテスト結果）を取得するのに時間がかかるので、
詳細を取得するか、しないかを選択できるようにします。