ということでバグ追跡にはMantisを使い出してみたんですが、SCMとの連携に関してはSubversionとのものしか情報が得られません。

具体的にはSubversionのpost-commitフックを利用し、checkin.php というスクリプトにコミットログを含むコメントを食わせ、その中に特定のキーワードがあればチケットのステータスを変更させる、というものでした。

 

って、Gitにもばっちりhookってありますよね。しかも post-commit ってそのまんまのやつが。もしかするとこれをいじることで、同様のことができるんじゃないでしょうか？

 

ものは試し、早速やってみました (^^)b
ざっくりとした設定の内容は続きに。

では、Mantisのドキュメントにある内容を参考に進めてみます。

まず、SCMからチケットを弄ぶため、Mantisに専用ユーザを作れ、とのこと。何も考えずに”gituser“にしてみます。

続いて、Mantisの設定ファイル(/config_inc.php)に、checkin.php向けの設定情報を追記します。

• $g_source_control_account
  SCMがMantisで使用するアカウントを指定します。このアカウントには「開発者」以上のロールを設定しておく必要があります。
  デフォルトは未設定なので設定が必須。
• $g_source_control_notes_view_status
  コメントの公開(VS_PUBLIC)/非公開(VS_PRIVATE)を設定します。デフォルトはVS_PRIVATE(非公開)。
• $g_source_control_regexp
  コミットログからチケットIDを拾い上げるための書式を正規表現で指定します。
  デフォルトは”/\bissue [#]{0,1}(\d+)\b/i”。
• $g_source_control_fixed_regexp
  ステータス、解決状況を変更するチケットIDの書式を正規表現で指定します。
  デフォルトは”%source_control_regexp%” ($g_source_control_regexpを参照する)。
• $g_source_control_set_status_to
  $g_source_control_fixed_regexpに一致したチケットに設定するステータス。デフォルトはOFF。
• $g_source_control_set_resolution_to
  $g_source_control_fixed_regexpに一致したチケットに設定する解決状況。デフォルトはFIXED。

 

とりあえず最低限、

$g_source_control_account = “gituser”; 

は追記が必要のようですね。

 

Mantis側の設定はひとまずこれで完了。続いてGit側をいじります。

 

連携させたいGitリポジトリのhooksディレクトリに、post-commit というファイルを探します。
リポジトリがローカルリポジトリであれば .git ディレクトリ下 、リモートなど bare なリポジトリであればディレクトリ直下に hooksというディレクトリがあり、その中に入っているはずです。

ローカルリポジトリだと
 /home/git/repo/.git/hooks/post-commit
bareなリポジトリだと
 /home/git/repo.git/hooks/post-commit

てな感じでしょうか。

 

これがgit commit した際に起動されるhookスクリプトです。
ここに必要なデータを抜き出しMantisへ渡すような処理を書いてやればOKなはず。。ですよね。

 

さて、まずはコミットログを取得しなければいけませんね。

 

git でコミットログを参照するには・・・はい、そのまんま git-log(もしくは git log)コマンドが使えます。出力内容についても細かく指定できるようですが、今回はとりあえずCommitのHash・ユーザ(Author)・日付とコメントがあれば問題なさそうです。git-logはそのまま叩くと今までのログをでろでろでろっと吐き出してくれますが、今回は最新の1件だけが必要ですね。

ということで、コミットログの取得コマンドはこんな感じになりました。

 

git-log --pretty=medium -1 --encoding=utf8

 

--pretty で一応出力書式をmediumに指定し、-1で1件のみ出力を指示しています。エンコーディングはデフォルトでUTF-8ですが、まぁ念のため。

 

あとはこのコマンドの出力をMantisのcheckin.phpに食わせてやればAOKなはず！

最終的な post-commit スクリプトはこんな感じになりました。ディレクトリやコマンドパスは適宜読み替えてください。

 

#!/bin/sh
#
# An hook script that is called after a successful commit is made.
# 

gitlog=/usr/bin/git-log
php=/usr/local/bin/php
checkin=/home/bts/htdocs/core/checkin.php

$gitlog --pretty=medium -1 --encoding=utf8 | $php $checkin

 

んー、シンプルぅ。

 

では早速テスト。
Mantisにダミーチケットを登録します。チケットIDは仮に 0000001 としておきますね。

そして、post-commit フックを弄んだ git リポジトリでなにかファイルを作るなり編集するなりし、git add しておきます。

さていよいよコミット。

git commit でエディタが起動しますので、なにかコメントを書いておきます。ここに記入したコメントはそのままMantisのチケット・コメントとして登録されるはずです。

コメントのどこかにキーワードとチケットIDを忘れずに。

 

バグ(#0000001)対応のため、xxxxx.php を修正

issue #0000001

 

こんな感じでしょうか。「バグ(issue #001)対応のため・・・」でもいいかも。
で、エディタを終了すると commit 処理が走ります。無事にエラーもなく完了しましたか？

 

さて、ではMantisを開いて、先程登録した #0001 のチケットを見てみます。
おお、無事にステータスが「解決済」、解決状況が「実装済」になっています！！

 

ぬぅ、こんなあっさりできるとは＾＾；；

Mantisが凄いのか、Gitが凄いのか、はたまたその両方か。

 

今回はローカルリポジトリでテストしましたが、次はリモートのbareなリポジトリでチャレンジしてみます。リモートの場合 post-commit より post-update の方がいいのかな？とか思ってみたり。

2008年12月22日　追記:
リモートリポジトリの場合はやはり post-update hook を利用すると実現できました。
スクリプト自体は上記のままでもOKっぽいです。
が、スクリプトの引数として <旧Hash> <新Hash> が渡ってくるっぽいので、git-log のオプションに 旧Hash..新Hash を付加するとpushまでの間に複数回commitされても拾える、、のかも。
その辺はまた後日実験します＾＾；

 

以上、ばしばし突っ込みお待ちしておりますm(_ _)m

タグ: BTS, git, Mantis, SCM

この投稿は 2008/12/18 19:05 に ソフトウェア, 仕事的メモ カテゴリーに公開されました。 この投稿へのコメントは RSS 2.0 フィードで購読することができます。 コメントを残すか、ご自分のサイトからトラックバックすることができます。