r-labs » Hudson

時間もあったほうがいいよな…と。

とりあえずこっちは置いておくので。新規に戻す。

Jens さんからお返事。

Really cool. 
I think this is a great way to indicate the status of the project code.

いい感じの方法だと思う。

In my eyes, any job (maybe two or more) should be displayed which builds this code. 

私からすれば、そのコードをビルドした幾つかのジョブが表示されるはずだ。

For example, we have a hudson job which builds our code and makes some small unit tests. 

例えば、私たちはコードのビルドと、小さなユニットテストのためのジョブを持ってる。

Another hudson job starts at night and makes some big integration tests. 

他のジョブは夜中に始まって、大きな結合テストをする。

So the build result should not be displayed at the top of the revision box. 

だから、ビルド結果はリビジョンの先頭に表示するべきじゃないんだ。
（なるほど！確かにそうだ。）

Instead it should be displayed in front of each build message(jobname, number, date). 

むしろ、結果は それぞれのビルドメッセージの前に出たほうがいい。

Please look at the screenshot attached for further details.

詳細はスクリーンショットを見てくれ。
（Success か Failure が頭に表示されてる。確かに）

>> This feature requires build info, so plugin may save a build info to database. (will work for show activities)
>> So what do you think?

How do you want to implement this?

君はどうやって実装したいんだい？
（どう思う？は、全体にかけたつもりだったんだけど、こういう場合は活動履歴もでるようになるよと書けばよかったか）

In my eyes, the hudson plugin has to automatically request in background the hudson 
instance for new builds of the configured jobs in each project. 
Maybe you can build  this via a timer which can be configured in hudson settings 
(request all 5|10|20|30... minutes).

プラグインは自動的にHudsonのビルド情報を取得すべきだろうね。
設定でタイマーを変更できるように。
（うーむ。定期的にジョブを動かす方法ってあるんだったっけ？）

In this case, you have to store information which build of which job is processed 
already and which ones are new and have to be processed. 

この場合は、情報を蓄積しないといけない。
どれが終わったか、新しいのはどれか、処理すべきなのはどれか。

For example, you can use the tag buildnumber in the xml representation 
((https://hudson.jboss.org/hudson/job/devstudio-nightly-2.0.x/api/xml)) of a hudson 
project to get the current build number and compare this to the number stored in database. 
I think parsing the last changes of a hudson job and get out the revision/bug number
is not too hard.

例にあげると、ビルドのタグを使うことができる。XMLの中にあるやつ。
カレントのビルド番号を取り出して、データベースにあるやつと比較する。
最後の変更をパースして、リビジョンやバグ？番号を取り出すのはそんなに難しくないと思う。

What about the amount of data?
Ok, let us say we have three jobs for a redmine project. 

データ量について？
OK、私がもってる3つのRedmineプロジェクトについて話すよ。

Two jobs are builded several times (20-30 times) one day. 
The third job is only builded once at night. 
The project duration is 200 working days year. 
So there are 6200 (200 days * 30 builds * 2 jobs + 200 days *1 build *1 job) entries 
in the database for this project. 
Hmm, I think it is ok.

2つのジョブは20～30回くらい一日にビルドされる。
3つ目のジョブは、夜に一度だけ。
このプロジェクトの期間は200日くらい。
そうすると、6200(200日 * 30ビルド * 2ジョブ + 200日 * 1ビルド * 1ジョブ)エントリだが
データベースにあるわけだ。大丈夫じゃないかな。

• ビルドの表示は、Jensさんのアドバイスの通りにしよう。
• Hudsonへのポーリングは、やったことがないので、できるかどうか分からない。
  リポジトリの場合は、表示したときに最新の情報を取得しているみたいだから、そっちの方法でいくかも。（もし定期的にポーリングする方法を知ってたら教えてほしい）
• DBについてはあまり問題なさそうだね。
  ChangeSetのためのエントリも増えるだろうけどそこまでひどいことにはならないと思う。

という返事を書く。

お返事完了。というわけで担当おしまい。
Background で動作させる方法教えてくれたら…やるしかないだろうなぁ。うむ。

チェンジセットr193で適用されました。