プロジェクト

全般

プロフィール

Feature #75

完了

チケットに関連づいたリビジョンがビルドされたら、履歴にビルド番号が追加される

Toshiyuki Ando さんがほぼ15年前に追加. 14年以上前に更新.

ステータス:
終了(Closed)
優先度:
通常(Normal)
担当者:
対象バージョン:
開始日:
2009/06/07
期日:
2009/06/14
進捗率:

100%

予定工数:
作業時間:

説明

やりたいこと

  • チケットを作る
  • コードをリポジトリにコミットする(コミットログでチケットに関連付ける)
  • コミットしたコードがビルドされる
  • ビルド番号がチケットの履歴に追加される

ビルド番号の表示について

チケットに表示されている「関係しているリビジョン」に、
ビルドが終わっていたら、そのビルド番号と、ビルドが終わったアイコンを表示するよう細工する。

考えどころ

ビルド番号とリビジョン番号の関連付けをどうするか?
見やすい感じがいいよなぁ。

リビジョン r100 と r101 が ビルド100 でビルドされました

くらい?

できれば、関連するリビジョンの欄に、ビルドで適用されたものは
"ビルド 100 で適用" とか出てくれると嬉しい。
⇒ JavaScriptでやってみよう

こんな感じでいいのかな?

ビルドごとに結果はだすので、こっち。


ファイル

Toshiyuki Ando さんがほぼ15年前に更新

まずは、チケットの表示にどうやって割り込むのか、その方法を考える。

CodeReview がその方法を知っているはず。<< lib/code_review_application_hooks.rb だ!

Toshiyuki Ando さんがほぼ15年前に更新

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ないのだろうか?

Toshiyuki Ando さんがほぼ15年前に更新

  • ステータス新規(New) から 担当(Assigned) に変更

Toshiyuki Ando さんがほぼ15年前に更新

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でレンダリングをお願いしているのだけど)。

さて。どれかいいのはあるだろうか?

Toshiyuki Ando さんがほぼ15年前に更新

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 を埋め込んで、関係しているリビジョンの内容を変更できるか
試してみよう。

Toshiyuki Ando さんがほぼ15年前に更新

関連するリビジョンを取得する方法

  • div (id = issue-changesets ) を探す
  • div (class = changeset) を探す
  • <p> を探す…(ここにもクラスが設定されていれば…)
  • <a> を探す
  • <a> の innerhtml を表示してみる

ここまでいけるかな?

Toshiyuki Ando さんがほぼ15年前に更新

なんとかいけそう。
ビルドが失敗してた場合は、どうしよう?

Toshiyuki Ando さんがほぼ15年前に更新

  • ファイル redmine_hudson_add_build_message_to_issue.png を追加

Toshiyuki Ando さんがほぼ15年前に更新

  • ファイル を削除 (redmine_hudson_add_build_message_to_issue.png)

Toshiyuki Ando さんがほぼ15年前に更新

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

Toshiyuki Ando さんがほぼ15年前に更新

とりあえず、 redmine.org でも聞いてみる。
結局この機能を実装するには、

  • すばやくビルドの情報を取得する必要があって
  • それにはDBに情報を溜め込んでいたほうがよくって
  • そうすると活動にビルドの情報を出せるようになる

と、やることが多い(し、釣られて機能も増える)のであった。
じゃ、まずは、DBに情報を溜め込む=活動にビルド情報を出す に手を付けよう。

Toshiyuki Ando さんがほぼ15年前に更新

  • ステータス担当(Assigned) から 新規(New) に変更

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

Toshiyuki Ando さんがほぼ15年前に更新

  • ステータス新規(New) から 担当(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ジョブ)エントリだが
データベースにあるわけだ。大丈夫じゃないかな。

Toshiyuki Ando さんがほぼ15年前に更新

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

という返事を書く。

Toshiyuki Ando さんがほぼ15年前に更新

  • ステータス担当(Assigned) から 新規(New) に変更

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

Toshiyuki Ando さんが14年以上前に更新

  • ステータス新規(New) から 解決(Resolved) に変更
  • 進捗率0 から 100 に変更

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

Toshiyuki Ando さんが14年以上前に更新

  • 対象バージョン0.2.0 から 0.1.5 に変更

Toshiyuki Ando さんが14年以上前に更新

  • ステータス解決(Resolved) から 終了(Closed) に変更

他の形式にエクスポート: Atom PDF