Proposal #51
完了活動ページにビルド履歴を出す
Toshiyuki Ando さんがほぼ15年前に更新
ビルドの履歴をDBに持つのは、Hudsonの流儀に反しそう?でちょっと気が引けます。
活動ページに表示している様々な履歴を管理する方法を知らないので、
そこを知ることから始めますね。
Toshiyuki Ando さんがほぼ15年前に更新
Redmine.org に出したら、そこでも要望が。
意外と多いのかもしれませんね。
もう少し様子見して、多そうなら考えます。(多分リポジトリの履歴と同じはず?)
Toshiyuki Ando さんがほぼ15年前に更新
リポジトリの履歴はどうなっているんだろう?と思って、DB見てみたら…
なんと! ファイル1つ1つの状態まで全部保存しているんですね。こりゃぁスゴイ。
うちのプロジェクトも長いけど、件数どのくらいになっているんだろう…。
Toshiyuki Ando さんがほぼ15年前に更新
サマリに何を登録しようか?というのは考えてなかったです。
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件行かないし。
うーん。やってみるかな。
Toshiyuki Ando さんがほぼ15年前に更新
- 期日 を 2009/06/21 にセット
- 優先度 を 低め(Low) から 高め(High) に変更
- 対象バージョン を backlog から 0.2.0 に変更
#75 の実現のためにこちらに手を付けることになりました。
明日中にできるといいんだけどなぁ。
Toshiyuki Ando さんがほぼ15年前に更新
ジョブ、ビルド、チェンジセットの情報を蓄積することにする。
上記の情報は現在ハッシュで管理しているので、これを全部クラス化…。
とりあえずは終了。
最初からクラスにしておくのがいいのかなー。Rubyの場合そうコストは高くないし。
Toshiyuki Ando さんがほぼ15年前に更新
仕方ないので rssAll で取れる分だけとることにした。
初回取得時(ものすごく時間がかかる)と、更新時のパターンを分けないといけない感じ。
あー。面倒。
Toshiyuki Ando さんがほぼ15年前に更新
ついでなので、Changeset や Artifact も保存できるようにしよう。
で、備忘録。
- 今まさにビルド中であったものについて
は、後からビルドの情報を再取得しないといけない。
あぁ。やること多いなぁ。
Toshiyuki Ando さんがほぼ15年前に更新
ひとまずChangesetまで保存できるようになったけど、
かなりエラー処理しっかりしとかないと、すぐ整合性が崩れそうだ…。
Repositoryまでとは言わないけど、かなり大変なことに手を出した気がするぞ…。
Toshiyuki Ando さんがほぼ15年前に更新
一旦整理のために、処理の流れをかいてみる。
index の表示処理¶
おおまかに分けて以下の処理がある。
1. DBからジョブの情報を取得する
2. ジョブの情報を更新する
3. ビルドの情報を更新する
DBからジョブの情報を取得する¶
- ジョブの情報を取り出す。
- 最新のビルド情報を取り出す。 ここでやるべき処理ではない
ジョブの情報を更新する¶
- HudsonAPIをノックして、ジョブの一覧と最新ビルドを取得
- ビルドの情報がDBにない場合は新規に登録する
- ヘルスレポートを取得する ここでやるべき処理ではない
ビルドの情報を取得する¶
- rssLatestを使って各ジョブの最新ビルド情報を取得する
- DBの最新ビルド番号と異なる場合に、以下の処理を行う
- HudsonAPI(各ジョブのrssAll)をノックして、ビルド情報を取得する
本来はDBの最新ビルド番号以降から、現時点での最新ビルド番号までとしたいのだけど、方法が分からない。 - DBに保存していないビルドの場合に、以下の処理を行う
- HudsonAPI(各ジョブのrssAll)をノックして、チェンジセットの情報を取得する
- ビルドとチェンジセットの情報を保存する
- HudsonAPI(各ジョブのrssAll)をノックして、ビルド情報を取得する
- 最後にジョブの最新ビルド番号を更新する
Toshiyuki Ando さんがほぼ15年前に更新
さて、今回はどのへんで整合性が必要となるか?
- DBに登録されているジョブの最新ビルド番号と、ビルドの情報
- ビルドの情報とチェンジセットの情報
これくらい?
- チェンジセットの情報を取得できなかったら、ビルド情報は保存しない。
- 最新のビルド情報を取得中に、1件でもエラーが発生したら、ビルド情報は取得できなかったとする
- ビルド情報を取得中に、エラーが発生したら、最新のビルド情報は更新しない
2つ目のルールはちょっと厳しいなぁ。途中が抜けるのはいやなので、
- チェンジセットの情報を取得できなかったら、ビルド情報が取得できなかったことにする。
- 最新のビルド情報を取得中に、1件でもエラーが発生したら、成功した分を保存する
- ビルド情報を取得中に、エラーが発生したら、成功したビルドの中で最新のビルド情報を保存する
かなぁ。エラーの情報はどう扱おうか。
Toshiyuki Ando さんがほぼ15年前に更新
ふと思ったけど、Hudson の不具合でジョブの情報が取れない場合もあるので、
エラーが発生したビルドのコトはとりあえず置いとく。というスタンスを取ろう
- ビルド情報を取得中にエラーが発生しても、とりあえず全てのビルドの情報を取得する
- エラーの内容によって、ビルド情報を取得するべきか、そうでないのか判断したほうがよさそうだ
- チェンジセットの情報を取得できなかった場合でも、とりあえずビルド情報は保存する
- エラーが発生した旨を登録できればいいだろう。
- ジョブの最新ビルド番号は、取得に成功したビルド情報の中で、一番新しいものにする
とは言え、エラーが発生したビルドを放っておくのもかわいそうだし、
どうやってリカバリーしたものか。リトライを手動でできるようにしておくかな?
ということは、取得したビルド情報を見れたほうがいいってことだよなぁ…。
Toshiyuki Ando さんがほぼ15年前に更新
Haru Iida wrote:
エラー時のリカバリは取りあえず放っておけばいいんじゃないでしょうか。
まずはシンプルに作って後から機能を追加していってしまえば。
なるほど。
Redmine だけの問題じゃなくなるので、エラー周りはある程度ユーザに親切にしておきたいなぁ
と思っているのです。はい。
が、あんまり長いこと放置状態もよくないので、そろそろかなぁ。
なんとなく、RSSは取れるけど詳細は取れないっていうケースはまず起こらないんじゃないかと。多分どちらも元ネタは同じだと思うので。
実はあったりするんですよ。Changeset まで含めると。
RSSが取れなかったら多分次回アクセス時に勝手に取れなかったところ以後を取りにいくことになるんですよね?
これは結構悩みどころで、エラーコードによるのかなぁと思っていたり。
500 系は取りに行く価値があるけれど、400系ってもう一度取りに行って成功する確率あるのかな?と。
もしかすると、
- エラーがおきたことは分かるようにしておいて、自動では取りに行かない
が正解かもしれません。
Toshiyuki Ando さんがほぼ15年前に更新
とりあえずビルド情報までを保存できるようにして、活動履歴を出してみます。
activity_provider/acts_as_event/acts_as_activity_provider
を解説しているところはないですよね…。
Toshiyuki Ando さんがほぼ15年前に更新
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
Toshiyuki Ando さんがほぼ15年前に更新
詳しい情報を取得する。
詳細な情報は http://{$HudsonURL}/job/{$JobName}/api/xml?depth=1 から取得する。
取得できる件数は、 http://{$HudsonURL}/job/{$JobName}/rssAll で取得できる件数と同じ¶
ビルド中のものがあった場合は、1件多くなるかもしれない。
変更(Changesets)が取得できる¶
変更した人/日時/リビジョン番号/コミットメッセージ/あれこれ
でも、チェンジセットは Repository モジュールが管理してくれているから、番号だけあれば十分。
テストの結果が取得できる¶
トータルの件数/失敗した件数/スキップした件数(って何だろう?)
成果物が取得できる¶
表示名/ファイル名/ダウンロードする際のURL
成果物はファイルだったりフォルダだったり、ビルドの設定によって異なる。
フォルダの場合?は、表示名やファイル名がないっぽいので、その辺を判断材料にするか。
使い道¶
さすがに詳細なだけあって、大きなビルドだと返事がかえってくるまでに時間がかかる。
なので、
- rssAll で情報を取得して、更新しないといけない場合にのみ、 api を呼び出す
ほうがストレスが溜まりにくそう。
とりあえず、テスト結果の取得から。
Toshiyuki Ando さんがほぼ15年前に更新
テスト結果と変更が保存、活動の履歴に表示できるようにしました。
今まで取得したテスト結果と変更を取得するには、履歴を全て消す必要があります。
設定画面の「履歴を削除」ボタンをクリックすると履歴が全て消えるので、
その後 Hudson タブにアクセスしてください。
ビルドの情報を更新するタイミングは、Hudsonタブにアクセスしたとき。
複数の人が同時にアクセスするとなんだかやばそうな気がする。
どうやって排他制御しようか。
Toshiyuki Ando さんがほぼ15年前に更新
大きなプロジェクトのビルドだったり、Hudsonがインストールされている端末が非力な場合は
ビルドの詳細(変更やテスト結果)を取得するのに時間がかかるので、
詳細を取得するか、しないかを選択できるようにします。
Toshiyuki Ando さんがほぼ15年前に更新
- ステータス を 担当(Assigned) から 解決(Resolved) に変更
- 進捗率 を 50 から 100 に変更
以降の実装は、他のチケットでやります。