最後までてんぱる

work

アルバイト

不安と焦りと期待と決意が混ざった感じ。

開発方法論改善提案 改め 所感

半分ぐらいできてるんだけど、それどころじゃなくなってしまって、、、。

Trac のクロスリファレンスプラグイン

それどころじゃない理由。私がいるときに運用にのせないと、と決意して、昨日サーバ管理者にお願いして社内の Trac の本番環境へ追加してもらった。一見、ちゃんと動いてそうに見えたんだけど、いくつか不具合が出てる。

  • リポジトリへコミットしたときののコミットログを Trac に書き込むフック処理がエラーになる

trac へアクセスしたときは、その環境毎のディレクトリ配下にある eggs/ ディレクトリを使っていた。TracPlugin: Setting up the plugin cache によると、PYTHON_EGG_CACHE をコミットログのフックスクリプト内で定義しないとダメなようで、フックスクリプトから呼ばれる commit_updater が egg キャッシュを www-data のホームに作ろうとして、そのディレクトリがないとエラーになってた。取りあえず www-data のホームに egg キャッシュディレクトリを作ることでエラーは回避できた。

これまでどうやって動いてたの？というのが気にかかるのと、本来は1つの egg キャッシュディレクトリに統一する方が望ましいから後で環境を見直す。

ログから現象を確認しただけ。クロスリファレンスプラグインが悪さをしてるのかどうかまだよく分かってない。

  • チケットページの番号の文字列をハイパーリンクに変換する処理や css/js を追加する処理が行われないことがたまにある

このフック処理内部でエラーが起きてるのかな？と思っていたけど、DEBUG ログを見てたら、そもそもフック処理が呼ばれてないように見える。リロードしたら直る (フック処理が呼ばれる) ので運用的に大きな課題ではないけど、かっこ悪いから直したい。でも、何だろうね？

TimingAndEstimationPlugin の TicketPropsLayoutChanger で追加している whitespace_remover.js がカスタムフィールドの HTML の構造や属性を書き換えてしまうみたい。詳細はまだ追ってないけど、ローカルの開発環境で再現できたから何らかの対応はできると思う。先にこれをやっつけて気分をのせる。

クロスリファレンスプラグインそのものの処理でエラーになっているわけではないように見えるんだけど、まだよく分からないし、ともかく何とかする。