Feature #75
closedチケットに関連づいたリビジョンがビルドされたら、履歴にビルド番号が追加される
Added by Toshiyuki Ando over 15 years ago. Updated over 15 years ago.
Description
やりたいこと¶
- チケットを作る
- コードをリポジトリにコミットする(コミットログでチケットに関連付ける)
- コミットしたコードがビルドされる
- ビルド番号がチケットの履歴に追加される
ビルド番号の表示について¶
チケットに表示されている「関係しているリビジョン」に、
ビルドが終わっていたら、そのビルド番号と、ビルドが終わったアイコンを表示するよう細工する。
考えどころ¶
ビルド番号とリビジョン番号の関連付けをどうするか?
見やすい感じがいいよなぁ。
リビジョン r100 と r101 が ビルド100 でビルドされました
くらい?
できれば、関連するリビジョンの欄に、ビルドで適用されたものは
"ビルド 100 で適用" とか出てくれると嬉しい。
⇒ JavaScriptでやってみよう
こんな感じでいいのかな?
ビルドごとに結果はだすので、こっち。
Files
redmine_hudson_add_build_message_to_issue.png (5.69 KB) redmine_hudson_add_build_message_to_issue.png | Toshiyuki Ando, 06/20/2009 11:36 AM | ||
redmine_hudson_add_build_message_to_issue_2.png (6.52 KB) redmine_hudson_add_build_message_to_issue_2.png | Toshiyuki Ando, 06/22/2009 02:44 PM |
Updated by Toshiyuki Ando over 15 years ago
まずは、チケットの表示にどうやって割り込むのか、その方法を考える。
CodeReview がその方法を知っているはず。<< lib/code_review_application_hooks.rb だ!
Updated by Toshiyuki Ando over 15 years ago
CodeReview の行っているHook は View に対する Hook は、以下のような仕組み。
- Redmine::Hook::ViewListener を継承したクラスを用意する
- init.rb で require する
- views/layouts/base.rhtml で画面をレンダリングする時に、Hook がよばれる
base.rhtml では、以下の種類の Hook が呼び出される。
- view_layouts_base_html_head
- view_layouts_base_sidebar
- view_layouts_base_content
- view_layouts_base_body_bottom
チケットのViewにはHookないのだろうか?
Updated by Toshiyuki Ando over 15 years ago
- Status changed from 新規(New) to 担当(Assigned)
Updated by Toshiyuki Ando over 15 years ago
Hookを呼び出す場合は、 call_hook という関数を使うようだから、
Redmine全体を call_hook で探してみればいいかもしれない。
結構出てきた。
- app/views/issues/bulk_edit.rhtml
- app/views/issues/_sidebar.rhtml
- app/views/issues/context_menu.rhtml
- app/views/issues/_form.rhtml
- app/views/issues/_history.rhtml
- app/views/issues/_edit.rhtml
- app/views/issues/show.rhtml
⇒ 関係しているリビジョン はここで表示される(正しくはpartialでレンダリングをお願いしているのだけど)。
さて。どれかいいのはあるだろうか?
Updated by Toshiyuki Ando over 15 years ago
app/views/issues/show.rhtml では、以下の Hook が使える。
- view_issues_show_details_bottom
⇒ チケットの内容を拡張する場合に。 - view_issues_show_description_bottom
⇒ 内容を表示し終わった後に何かする?場合に。
view_issues_show_description_bottom を使うべきだろうけど、
関係しているリビジョン は、view_issues_show_description_bottom の後に表示される…。
とりあえず、ここに JavaScript を埋め込んで、関係しているリビジョンの内容を変更できるか
試してみよう。
Updated by Toshiyuki Ando over 15 years ago
関連するリビジョンを取得する方法
- div (id = issue-changesets ) を探す
- div (class = changeset) を探す
- <p> を探す…(ここにもクラスが設定されていれば…)
- <a> を探す
- <a> の innerhtml を表示してみる
ここまでいけるかな?
Updated by Toshiyuki Ando over 15 years ago
- File redmine_hudson_add_build_message_to_issue.png added
Updated by Toshiyuki Ando over 15 years ago
- File deleted (
redmine_hudson_add_build_message_to_issue.png)
Updated by Toshiyuki Ando over 15 years ago
- File redmine_hudson_add_build_message_to_issue.png redmine_hudson_add_build_message_to_issue.png added
時間もあったほうがいいよな…と。
Updated by Toshiyuki Ando over 15 years ago
とりあえず、 redmine.org でも聞いてみる。
結局この機能を実装するには、
- すばやくビルドの情報を取得する必要があって
- それにはDBに情報を溜め込んでいたほうがよくって
- そうすると活動にビルドの情報を出せるようになる
と、やることが多い(し、釣られて機能も増える)のであった。
じゃ、まずは、DBに情報を溜め込む=活動にビルド情報を出す に手を付けよう。
Updated by Toshiyuki Ando over 15 years ago
- Status changed from 担当(Assigned) to 新規(New)
とりあえずこっちは置いておくので。新規に戻す。
Updated by Toshiyuki Ando over 15 years ago
- Status changed from 新規(New) to 担当(Assigned)
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ジョブ)エントリだが
データベースにあるわけだ。大丈夫じゃないかな。
Updated by Toshiyuki Ando over 15 years ago
- File redmine_hudson_add_build_message_to_issue_2.png redmine_hudson_add_build_message_to_issue_2.png added
- ビルドの表示は、Jensさんのアドバイスの通りにしよう。
- Hudsonへのポーリングは、やったことがないので、できるかどうか分からない。
リポジトリの場合は、表示したときに最新の情報を取得しているみたいだから、そっちの方法でいくかも。(もし定期的にポーリングする方法を知ってたら教えてほしい) - DBについてはあまり問題なさそうだね。
ChangeSetのためのエントリも増えるだろうけどそこまでひどいことにはならないと思う。
という返事を書く。
Updated by Toshiyuki Ando over 15 years ago
- Status changed from 担当(Assigned) to 新規(New)
お返事完了。というわけで担当おしまい。
Background で動作させる方法教えてくれたら…やるしかないだろうなぁ。うむ。
Updated by Toshiyuki Ando over 15 years ago
- Status changed from 新規(New) to 解決(Resolved)
- % Done changed from 0 to 100
チェンジセットr193で適用されました。
Updated by Toshiyuki Ando over 15 years ago
- Target version changed from 0.2.0 to 0.1.5
Updated by Toshiyuki Ando over 15 years ago
- Status changed from 解決(Resolved) to 終了(Closed)