2012-03-15 4 views
0

ビルドに失敗した場合にtracで新しいチケットを自動的に作成する可能性を探しています。問題は、ビルドを壊した人にチケットを割り当てる必要があることです。 チケットを作成するのにTicketToTracScriptを試しましたが、チケットの担当者を取得する方法がわかりません。ビルドが失敗した場合に自動的にtracのチケットを作成して担当開発者に割り当てる方法

+0

もう少し情報が参考になります。私。 Trac usernameと同じリポジトリにチェックインする際の作者ですか? – hasienda

+0

はい、同じユーザーです。 – user1127860

+2

私はジェンキンスをまったく知らない。あなたはその後、改訂版が作成できなかったことを知っていますか?はいの場合、リポジトリ内のリビジョンの作成者/コミッタを見つけることに至ります。コミッターがビルドを壊したと仮定すると、望ましくない影響が出ることになる。破損したソースが修正されるまで、コミッターは誰かに割り当てられたチケットを取得し、最初のチケットのみが正当な理由で非難される。 – hasienda

答えて

0

"チケットの責任者"とはどういう意味ですか?

チケットを登録するアカウントを指定している場合は、自動ビルドシステム用に個別のTracユーザーアカウントを作成することをお勧めします。このアカウントは、チケットを自動ファイルするスクリプトによってのみ使用されます。これは、通常、誰かの開発者アカウントを再利用しようとするよりはるかに簡単なルートです。

チケットを割り当てる人を意味する場合、私は簡単な答えがないことを恐れています。ビルドを破棄する責任者を特定することは、通常、ビルド結果のみに基づいて自動化することは非常に困難です。

エラーの原因となった違反の行番号がビルド出力に表示されている場合は、svn blameなどのバージョンコントロールシステムに類似の機能を使用して、その行を最後に変更した人が誰かを確認できます。しかし、実際にビルドを壊した人ではないかもしれませんが、それはあなたにスタートを与えます。私は、 "CC"フィールドのチケットの最後のビルド以降、問題のファイルを修正したすべての人物をリストアップし、最後にその人物をその人物の所有者として変更する人物をリストアップするシステムを見てきました。それは少なくとも問題を調査させ、必要に応じてチケットを再割り当てすることができます。

誰がビルドを壊したのかを知る唯一の真の方法は、問題の原因となったコミットを発見するまで、中間リビジョンを作成することです。あなたのリビジョンコントロールシステムが類似のものを提供するなら、git bisectのようなツールはこれには便利です。これはもちろん、完全なビルドを行うのにかかる時間の長さに完全に依存します。ビルドに45分かかる大規模なコードベースをお持ちの場合は、実際にはあまりにも時間がかかるでしょう。あなたのプロジェクトが、別々にビルドできる個々のコンポーネントに分割されている場合は、失敗したコンポーネントだけをテストビルドして、問題のあるコミットをすばやく特定することができます。

関連する問題