2015年10月27日火曜日

[Coverity] CEDEC 2015 で出題されたバグクイズ

バグクイズです!(CEDEC 2015 の問題) « Coverity Blog

CEDEC 2015 で出題されたバグクイズ。
私も実際に CEDEC に行って見てきたわけですが、
3日目の問題が直ぐに解けず、なんだか悔しかったのでこの記事を書いてる次第です。
(あーだこーだしているうちに2ヶ月も経ってしまいましたが…)

ちなみに、答えはこちらです。
CEDEC 2015 Tokyo でのバグクイズの正解を発表! « Coverity Blog

Coverity 以外では検出できないのか?

検証の際に実際に使用したソースコードはこちら。
https://github.com/srz-zumix/coverity_test/tree/master/cedec_coverity

Cppcheck v1.70
まずは、フリーで使える C++ 静的解析の定番となっている Cppcheck です。
使用したのは現時点での最新バージョンである 1.7.0 です。

残念ながら、どちらの問題も検出されませんでした。

Visual Studio コード分析
次に Visual Studio です。
Visual Studio にはコード分析機能が付いています。プロジェクトプロパティのコード分析で有効にできます。

これもかなり優秀なんですが…


残念ながら、どちらの問題も検出されませんでした。

gcc/clang
最後はコンパイラーです。
Visual Studio はコード分析のときにビルドしましたが、検出できなかったので既に脱落しております。

それぞれの結果です。


どちらも delete (void*)p の問題は検出されました。

scan-build
おまけです。
scan-build は clang の静的解析ツールです。
cygwin パッケージに入ってたので使ってみました。


結果としては clang コンパイラーと一緒で delete (void*)p の検出だけでした。

まとめ
Coverity すごい!!


2015年10月19日月曜日

[Jenkins] 同じノードで繰り返し実行されないようにする方法

Workflow Plugin を使ったらこれについても制御できるかもしれないですが、
まだ Workflow Plugin 使えてないので、別の方法を紹介します。

Groovy Label Assignment plugin
Groovy Label Assignment plugin を使います。
このプラグインを使うと Groovy を使って、
動的に実行ラベルを設定することができます。

ジョブの設定ページを開くと、
「Groovy スクリプトで実行するノードを制限」があるので有効にし、スクリプトを入力します。
文字列を返すとそれが新しいラベル式になります。なにも返さなかった場合は、もとのラベル式が使われます。


前回実行ノードを除外するときは、こんな感じに書きます。
def label = currentJob.assignedLabel
def last = currentJob.getLastBuild()
if( last == null ) return
def node = last.getBuiltOnStr()
if( node == null || node == "" ) node = "master"
if( node )
  return "${label}&&!" + node 
実行しようとしているジョブは currentJob にバインドされているので、そこからラベルと前回実行時のノード名を取得して新しいラベルを生成します。


さまざまなスレーブでまんべんなく実行したい場合はマトリックスを組むのが良いですが、この方法も覚えておくと便利かもしれません。

2015年10月13日火曜日

5年

このブログを始めて5年になったようです。
まさか、ここまでできるとは思ってませんでした。
5年間いろいろとありましたが、書いてる内容的にこの5年であまり変化がない感じなのも面白いですね。

さて、今から5年後、自分も含めてどうなってるんでしょうね。
それでは今後ともよろしくお願いします。

[Jenkins] Locale Plugin で表示言語を英語にして検索力アップ

Locale Pluginを使うと表示言語を強制的に変更できます。

参考:Jenkins がもっと便利になるおすすめプラグイン 8 つ (フェンリル | デベロッパーズブログ)


Jenkins 関係の調べごとをしていると、日本語表記で検索した場合にヒットしにくいことがあります。
英語表記で検索すればよりたくさんの情報を調べやすくなります。

というわけで、Locale Plugin を使いました。
調べたことはまたこのブログで紹介できると思います。
今回は以上。では。

2015年10月5日月曜日

[Jenkins] Warnings Plugin はとりあえずインストールしておけ

Warnings Plugin は警告ログなどを集計してくれるプラグインです。
デフォルトでたくさんのフォーマットに対応していて、独自定義も自由に作れて、
非常に便利でありがたいプラグインです。

便利なプラグインなので、ここで紹介するまでもなく既に使ってる方が多いのではないかと思います。
が、「とりあえずインストールしておけ」というまでのものかというと、
以前ここでも紹介した Groovy Postbuild Plugin と比べるとそうでもなかもしれません。

ブログズミ: [Jenkins] Groovy postbuild plugin はとりあえずインストールしとけ

ではなぜ、「とりあえずインストールしておけ」というかというと、便利だからという理由とは別の理由があります。

最新バージョンしかないプラグイン
ブログズミ: [Jenkins] プラグインのダウングレード
こちらの記事にも書いてありますが、Jenkins のプラグインは https://updates.jenkins-ci.org/download/plugins/ から古いバージョンをダウンロードしてくることができます。
ここで「すべてのプラグインの古いバージョンがある」と思い込んでいたのですが、
実はそうでもないようで旧バージョンがないプラグインもあるようです。

その1つが Warnings Plugin なのです。
しかし、古いバージョンがダウンロードできないからといって何か困ることがあるのか?
そう思う方も多いでしょう。

なにが困ったか
Jenkins のプラグインには Required Core として Jenkins 本体の要求バージョンというものがあります。
これが使っている Jenkins のバージョンよりも新しいと下のように警告されます。

困ったのはこれです。
とあるプロジェクトでは、 Jenkins が以前から使われていたものの、ほぼ素の状態で使われていました。
とあるタイミングでもっと便利にしたいとなり、Warnings Plugin を使おうとしました。
ところが、使っていた Jenkins はすでにかなり古いバージョンになっており、Warnings Plugin が要求するバージョンよりも古いものでした。

Jenkins のバージョンを上げるのは、結構ストレスです。
経験ある方ならわかると思いますが、バージョン上げた途端動かなくなったり、なんだか挙動がおかしくなったり、めんどくさーい嫌な思い出があるのです。
これが開発初期だったらよかったのですが…
かといって、Required Version を無視して使ってみて動いたらラッキーということもできないでしょう。


結局は Jenkins のバージョン上げて対応をしました。結果としては何も問題なかったです。
ただ正直、最初から Warnings Plugin をインストールしておいてほしかったな、と思いました。
プラグインのバージョンが古くても、少なくとも使えはしますから。


というわけで
旧バージョンが残されていないプラグインは、(便利なものであれば)最初にインストールしておきましょう!

私が使っているプラグインで旧バージョンがないプラグインは2つありました。
Dependency Graph Viewer Plugin
Warnings Plugin

追記
コメントいただきました。ありがとうございます。
Warnings プラグインの旧バージョンはこちらから取得できます。
http://maven.jenkins-ci.org/content/repositories/releases/org/jvnet/hudson/plugins/warnings/

これからは http://maven.jenkins-ci.org/content/repositories/releases/org/jvnet/hudson/plugins/ こっちも確認したいと思います。