投稿

Redmineのリポジトリから特定ソースの修正をGoogle Apps Scriptでメールする

イメージ
Redmineのプラグインを作成していると、関連する本体側の修正に影響を受けることがあります。
また、私の作っているRedmine XLSX format issue exporterは、RedmineのCSVエクスポート機能と同等を目指しているので、変更に追随するようにしています。

Redmine本体へのコミットは、MastodonDiscordのBOTで確認できますが、流してみる感じになるので見逃してしまいがちです。
CIで失敗する場合はいいのですが、スルーしてなんか動きがおかしくなったり、本体側のバグ修正をプラグイン側にも反映すべき場合があったりが続いたので、対策を考えて見ました、の結果です。

今回はGoogle Apps Scriptを使って見ました。Google Apps Scriptを使うと、cron的なトリガーでスクリプトを動かすことができます。
設定画面はこんな感じ。


作成したスクリプトは、redmine.orgのリポジトリページへアクセスして、今日のコミットがあればメールするというものです。
以下のような感じ。targetsにURLを追加していけば、複数のソースをチェックできます。


これでちょっとは見逃しが少なくなるといいんですが。。。

Redmineのチケットに表示されるSVNのコミット情報に対象ブランチを表示する

イメージ
Redmineのチケットとリポジトリを関連付けすると、そのチケットに該当のコミットが表示されます。

ここには、どのブランチへのコミットなのかの情報がありません。 これを解決しようと以下のプラグインが存在します。
Git Revision Branches

名前からGit専用と見せかけて、実はMercurialにも対応していました。
でも、私が欲しいのはSubversion!!!!!

というわけで、以下のプルリクエストを作成しました。
Subversion support.

これを入れるとSubversionでも以下のように表示されます。
Redmineはプロジェクトに複数のリポジトリが設定できるため、そのリポジトリ名と後ろにブランチが表示されます。

認識できるリポジトリは、Subversionの標準的な構成(trunk, branches, tags)を想定しています。
ただ、Redmine本家のリポジトリからして、sandboxというのがあるので、さすがにRedmineのプラグインだしなと思って、それも認識できるようにしました。
trunk以外はその1階層下まで表示する仕組みにしています。

また、一つのリポジトリに複数のプロジェクトを突っ込んでいるような構成も見かけます。
各プロジェクトの中に、さらにtrunkやbranchesなどがある、例えば、
http://example.com/svn/projectA
 /trunk
 /branches
 /tags
http://example.com/svn/projectX
 /trunk
 /branches
 /tags
みたいな感じのとき、Redmineのプロジェクト、もしくはリポジトリの設定が分かれていて、リポジトリの設定には、
http://example.com/svn/projectX
と指定すると思われます。
こういった場合にprojectX部分は邪魔なので、それを省く設定を入れました。
複数リポジトリを設定する場合を想定して、カンマ区切りで複数指定できるようにしました。

とりあえずこれで自分としては用が足りるとこまでいったかなという感じ。


【テスト設計】VSTePのファーストステップ 〜 新潟出張版 〜 に参加してきました

JaSST'18 Niigataの翌日に行われた、
【テスト設計】VSTePのファーストステップ 〜 新潟出張版 〜
に参加してきました。
JaSST'17 Tokyo のセッション「VSTePのファーストステップ 〜 JaSST'16東北出張おかわり会 〜」にて講演された、 JaSST東北実行委員のお二方を講師に迎えて行われました。
お二方、主催すわにいの@kasacchifulさん、お疲れ様でした&ありがとうございました!

内容はワークが中心で、ワークに当たって必要なVSTePのことを、はじめに座学でというものでした。座学は大きく、テスト観点図とテストコンテナについてでした。
具体的な図などは、connpassに記載のある参考してもらえればと思います。

テスト観点図 テスト観点は「テストの意図」。チームで納得のいく観点、観点のまとめを行う。チームで話し合う中での「違和感」を大事にする。
あのとき、なんかひっかかってたんだよな〜、というところでバグが出て後悔しないようにする。仕様書に書かれていることがすべてではない。チームの経験なども含めて観点を出していく。トップダウン、ボトムアップ、ズームイン、ズームアウトを繰り返し考えてみる。図にしたら、左右、上下の粒度を見ていく。
粒度があっていない箇所から抜け漏れが見えてくることが多い。 テストコンテナ テストを実施することを考えた、観点のグルーピングを行う。左から右へ、時系列にコンテナを並べる。
縦方向は並列に行えるもの。
テストの前後関係、実施順序、同時にできることなどが見える。チームとしてしっくりくる、納得できる括りにすることが大事。 ワーク +Lhacaの解凍機能について、テスト観点図、テストコンテナを作成するワーク。今回は6人のチーム。それぞれで仕様書をざっとみる。仕様書は見ないようにして観点をみんなで付箋に書き出していった。
仕様書を見ないことで、仕様書に書いていないことが出やすくなる。手を止めずにどんどん進めていくのが重要。出した付箋をツリー構造に整理していく。
整理する中で新しい観点がでてきたり、構造を変えるために加えたりと、いろいろ話しながら進めました。観点に出ていくる「言葉」を共通の理解で捉えているか、を確認するのも重要。
チームで同じものを見ていることが重要。バックボーンの違いから、…

[Redmine Advent Calendar 2017 1日目] shields.ioでredmine.orgのプラグインレイティングのバッヂを表示する

イメージ
Redmine Advent Calendar 2017の1日目です!

Redmineのオフィシャルサイトであるredmine.orgには、開発されているプラグインを確認できるPlugins Directoryがあります。

Plugins Directoryにプラグインを登録しておくと、Redmine上から最新バージョンのチェックも行えます(管理画面のCheck for updatesから行えます)。


しかし、ソースコードは別のリポジトリに登録してある状態になります。
例えばGitHubにソースを登録しておいた場合、READMEやWiki、Issuesなど、そこだけで足りてしまうのが実際のところです。
検索してGitHubに飛んだら、Plugins Directoryを見ることがない場合も多いと思います。

そこで何か誘導するものがあれば、Plugins Directoryで他のプラグインに巡り会う機械にもつながるな、ということで、Plugins Directoryのレイティングをバッヂとして表示する仕組みを考えました。
バッヂからPlugins Directoryへリンクしてレイティングしてもらう、というモチベーションでプラグイン開発者の方にも入れてもらいやすいかなと考えています。

shields.ioというサービスが、いろいろなサービスのバッヂを提供しています。
これにredmine.orgのプラグインレイティングが載れば、プラグイン開発者の方がみんなで使えるな、ということでプルリクエストを出したところ、入れてもらえました

以下はRedmine XLSX format issue exporterの GitHubにバッヂを入れた例です。
星がでるパターンですが、数字で出すパターンもあります。

READMEには、Markdownで以下のように記載してPlugins Directoryへリンクしています。
[![Stars](https://img.shields.io/redmine/plugin/stars/redmine_xlsx_format_issue_exporter.svg)](https://www.redmine.org/plugins/redmine_xlsx_format_issue_exporter) SVGのファイル名部分は、プラグインのPl…

Redmine Auto Assign Group Pluginを作りました!

イメージ
Redmine Auto Assign Group Pluginを作りました!

@akipiiさんが既にブログで取り上げてくださっています。ありがたや!
で、ブログ書いてないと気づいた。。。
きっかけredmine.orgのフォーラムに以下の投稿がありました。
Plugin to automatically assign new users to groups?

ユーザーの登録時に自動的にグループを設定したいという要求は、結構昔からあったようです。
上の投稿から参照されているスレッドは2012/04に開始されています。
パッチやプラグインの書き込みがありますが、条件によって別のグループを設定したい、というのが今回の投稿でした。

ユースケースとして挙げられていた、グループごとでアクセス権限を行なうような運用は、規模が大きかったり複数の組織が絡むようなときに、手間が大幅に削減できそうな感じがしました。
他にも思いつかないようなシーンが隠れてそうだなあとも思い、なんか既にありそうな感じ・・・と思ったんでググってもないから、面白そうだし作るか!ということにしました。
使い方 GitHubにインストール方法簡単な使い方を書きました。
グループの設定画面から、グループごとに正規表現でルールを設定できます。
ユーザーが追加された際に、ルールに合致するとそのグループに追加されます。
今後の方向性 とりあえず、正規表現のチェック機能が必要と思っています。
あとは、グループ横断でのルール一覧もあるといいかな、と思ったり、いらないんじゃないかな、と思ったり。
作ったばかりなので、フィードバックを頂いたら考えていこうかなあと思います。

RedmineプラグインでMroongaを使うときのテスト

Full text search pluginRedmine XLSX format issue exporterが競合した話。
パッチのロード順でチケットが表示(issues#show)できなった。
パッチを提示してもらい、パッチを適用する位置を変更して対処した。
https://github.com/two-pack/redmine_xlsx_format_issue_exporter/issues/50

ここからが本題。
いつも開発環境はsqlite3でやっているが、Full text search pluginがMroongaを使用するので、Unofficial Redmine CookingのRedmine AnsiblePlaybook Unofficial Cooking Edition(闇鍋版)を使用した。
すると、rake redmine:plugins:testでRedmine XLSX format issue exporterのテストを実行すると以下のようなエラーが出た。
Mysql2::Error: The used table type doesn't support FULLTEXT indexes: CREATE fulltext INDEX `index_issue_contents_on_contents`
調べて見るとdb/schema.rbにテーブル作成時のオプション指定が入らないことが原因。
プラグインでは以下のようなmigrateが書かれている。
create_table :issue_contents, options: "ENGINE=Mroonga" do |t| t.integer :project_id t.integer :issue_id, unique: true, null: false t.string :subject t.text :contents, limit: 16.megabytes t.integer :status_id t.boolean :is_private end 対してschema.r…

長岡IT開発者勉強会(NDS) 第52回勉強会に参加してきました #nds52

長岡IT開発者勉強会(NDS) 第52回勉強会に参加してきました。
http://nagaoka.techtalk.jp/no52
Togetterでまとめてくださっています。
https://togetter.com/li/1120966

今回のテーマは「初心者むけ」でした。
初心者とは・・・という哲学的な内容で非常に勉強になりましたw
メモを見ながら雑感です。へえと思ってばかりで何年やっても初心者だな、俺。。。

「はじめてのC#プログラミング」 ailightさん歴史的なあれ。N88BASIC、Quick C、Etc.... とても懐かしかった。caseのbreak漏れでコンパイルエラーとか、へえと思った。
機械、規約がうまく問題を解決してくれるのはうれしい。「分岐が複雑の始まりであることを理解する」、「ループは前処理と後処理がセットでループ」とか、その通りだなと思いつつ、普段から意識できているかというと怪しいと思った。。。
「なんてかんたんなJavaEE」 civicさんFull Profile / Web Profile / Micro Profile
薄いという選択肢があるのはいい。
「文字コードとプログラミング(仮)」 gonchan93さん「UNICODEを使え」、もうこれだね!wJavaのStringがメモリ節約の方向にという話は、へえと思った。
この辺の話。http://openjdk.java.net/jeps/254
「Netcatを使おう」 hayajoさんtelnetみたいなのか、と思ったらそれどころではなかった。すごいコマンドがあるもんだ!
「怖くないし役に立つ設計原則の話」 neko_gata_sさんDRY原則おじさん。いるわー、おれだわー、こぴぺするなーいってるわーorz「設計原則同士は関連している」というところに集約されていると思った。おまけのデザパタも含めて。話を聞くとうんうん、と思うけど、こうやって筋立てて話をできることや反例の出せることは、本当にすごいと思う。硬い、柔らかい、のあたりが、理屈はわかっても初心者には判断が難しいところだと思う。DRYにしないと!と言って見たり、こういう時は重複してもさ、とかいうことは確かにあるが、腑に落ちるように説明するのが難しいところ。
「はじめてのソフトウェアテスト(仮)」 kasacchifulさん工…