2017年2月27日月曜日

[CI][Wercker] Workflows を利用してテストのパラメタライズと並列化をしてみた

安定運用していたので、あまり見ていなかった Wercker から、もう non-Docker なやつはやめるから移行してやーってメール来たので、見てみたら Workflows という新機能が実装されていたので、ついでにその機能を使った CI に変えました。

Workflow についてはこちらを参照してください。
Manage complex CI/CD automation scenarios with Workflows

必要こととしては、wercker.yml にパイプライン処理を追加するのと、
Wercker のページ上で Pipelines と Workflows を構築する2点です。

パイプライン処理の作成(YAML)
wercker.yml の方はドキュメントとかを参考にこのように変更しました。(ちょっと長いです)

定義したパイプラインは2つで、wandbox と nothing です。
wandbox は iuwandbox を使用してテストコードを Wandbox に投げつけテストします。
CI サービス + Wandbox は以前にこのブログで紹介したので、そちらを参照してください。
ブログズミ: Shippable + Wandbox で C++ の CI 環境構築

wandbox パイプラインのポイントとして compiler と --std オプションを環境変数にしているところです。(IUWANDBOX_COMPILER と IUWANDBOX_CPPVER)
後述しますが、Wercker ではパイプラインごとに環境変数を設定できます
パイプラインは、YAML に書いたパイプライン処理と環境変数等のセットで、1つになります。
つまり、パラメータを環境変数にしておくことで、YAML の定義1つで、複数のパイプラインを作ることができるのです。

また、ワークフローのジョイント用に何もしない nothing パイプラインも用意しました。

wercker.yml の設定は以上です。
パイプライン・ワークフローの作成
続いて、Web 上でワークフローを作っていきます。
プロジェクトの設定ページを開いたら、「Workflows」があるのでそこを開きます。
Editor の下にフローっぽいのがありますが、まずはさらに下にある「Pipelines」でパイプラインを作っていきます。


「Add new pipeline」を押すと、以下のようなページが開くので、任意のパイプライン名と YAML に定義したパイプライン処理の名前を記入します。
「Hook Type」には、「Default(パイプライン連結)」と「Git Push」がありますので、用途に合わせて選択してください。今回はパイプラインを連結していくので、「Default」を選択しました。


「Create」ボタンを押すと設定ページが開きます。
ここで環境変数などが設定できます。(今回は IUWANDBOX_COMPILER と IUWANDBOX_CPPVER を設定)


これで1つ目のパイプラインができました。
あとは、同じことを環境変数を変えつつ必要なパターン分だけ用意します。
(これ結構めんどくさいんですけどね…)



パイプラインができたら、最後に Workflows です。
Workflows のページに戻ってきたら、Editor のところにあった + アイコンをクリックします。
下の画像のように、ブランチフィルターとパイプラインを選択するポップアップがでてくるので、選んで「Add」を押します。


あとは、同様に + をクリックして好きなように連結していきましょう。


以下は現時点(2017/2)での挙動における注意点

※ 1つのパイプラインを複数使用することはできません
※ 分岐したパイプラインを Join することはできません
※ パイプラインは40個以上作れるのですが、パイプライン追加のリストに入らいないため実質40個が上限になっています。

実行結果


最後に
パラメタライズドな感じでパイプラインを定義して自由にフローを組み立てられるのは非常に便利だなと思いました。(Jenkins もこんな感じにできないのかなぁ)

あとは Join ができるとすごく嬉しいですが、なくてもすごく便利に使えると思うのでオススメです!
今回は以上です。
では。

2017年2月21日火曜日

[雑記][Jenkins] Cppcheck Plugin のパイプライン対応がもうすぐ来そうな予感

こんにちは。
先日某所であった勉強会(?)で Jenkins おじさんたちと Jenkins なお話を久しぶりにしたので、滞ってた自宅 Jenkins のパイプライン化対応を再開しようかなと思ってます。

で、Cppcheck のパイプライン対応しようと思ったら、まだ対応してなくて保留していたのも思い出しました。

プラグインの対応状況
Plugin Compatibility with Pipeline : https://github.com/jenkinsci/pipeline-plugin/blob/master/COMPATIBILITY.md
こちらに主要な?プラグインの対応状況が載っています。
画像は2016年9月のときのものですが、現在もまだチェックがありませんでした。


しかし、issue を見てみると、もうすぐ更新ありそうな気配がしてました。
[JENKINS-35096] Add support for Jenkins Pipeline to the cppcheck-plugin - Jenkins JIRA

早く使えるようになってほしいですね!

※ 実は対応してないプラグインを頑張って使う方法を調べようとしてたんですが、https://github.com/jenkinsci/pipeline-plugin/blob/master/COMPATIBILITY.md を今見たらほぼほぼ対応してるっぽいので、待ちスタンスに切り替えました。

2017年2月17日金曜日

[Jenkins][Cppcheck] ソースファイルの文字化けを解消する

Windows 上で Jenkins を実行していると、エンコードが MS932 になっていることがほとんどだと思います。


この状態で Cppcheck Result から UTF-8 のソースコードを表示すると、日本語が文字化けしてしまいます。


この問題について質問を受け、対策を考えてみたのでまとめておきます。

Jenkins の文字コードを変更する方法
まず真っ先に出て来る方法は、エンコードを UTF-8 にする方法です。


対応はとても簡単です。
-Dfile.encoding=UTF-8 を Jenkins 起動引数に追加するだけで OK です。
java -Dfile.encoding=UTF-8 -jar jenkins.war --sessionTimeout=1440
サービスにインストールしている場合は、Jenkins.xml の <arguments> に追加してください。

Jenkins を再起動して見てみるとこのように日本語が正しく表示されるようになります。


問題点
ただし、この方法には問題点もあります。
Windows バッチ処理は通常 cp932 (sjis)なので、システムを UTF-8 にしてしまうと、バッチ出力が今度は文字化けしてしまいます。
そこで、バッチ処理の最初に「chcp 65001」する必要が出てきます。
chcp 65001 ナシとアリ、それぞれの結果が以下になります。




ただ、毎度毎度 chcp するのも面倒ですよね。
なので、別の方法も考えてみます。

Warnings Plugin を使って集計する
Cppcheck Plugin ではなく Warnings Plugin を使う方法です。
Warnings Plugin では設定にエンコーディング指定がありますので、こちらを設定すればシステムのエンコーディングと異なっていても大丈です。


Cppcheck の結果を Warnings Plugin で集計は3つのステップで対応します。

Cppcheck の出力カスタマイズ
Warnings Plugin で Cppcheck の結果を集計するために、まず Cppcheck の出力をカスタマイズします。
(デフォルトだと出力されない情報もあるので)
今回は以下のようにしてみました。
--template="{file}:{line}: {severity}: {id}: {message}"
(.+?):(\d+): (information|portability|performance|style|warning|.*error): (.+?): (.*)$


Warnings Plugin にパーサーを追加
続いて、Cppcheck の出力をパースするルールを追加します。
「Jenkins の管理」「システムの設定」の「コンパイラの警告」を開きます。


名前などはご自由に。
「マッピングスクリプト」に以下のようなスクリプトを設定してください。
import hudson.plugins.warnings.parser.Warning
import hudson.plugins.analysis.util.model.Priority

String fileName = matcher.group(1);
int lineNumber = Integer.parseInt(matcher.group(2));
String category = matcher.group(3);
String id = matcher.group(4);
String message = matcher.group(5);
Priority priority;

if (category.contains("error")) {
    priority = Priority.HIGH;
} else if (category.contains("information")) {
    priority = Priority.LOW;
}
else {
    priority = Priority.NORMAL;
}

return new Warning(fileName, lineNumber, id, category, message, priority);

ジョブの設定
最後にジョブの設定をします。
ビルド後の処理から「コンパイラの警告の集計」を追加。
パーサーには上で追加したパーサーを選択してください。


そして、「高度な設定」を開いて「デフォルトのエンコーディング」を設定してください。


設定は以上です。

結果

文字化けしてませんね^^

根本的解決を目指す
Cppcheck Plugin が Warnings Plugin のようにエンコード指定に対応できればいいわけです。
というわけで、やってみようと思っていたのですが…全然手が回らず…今回はここまでです。


今後の展開にご期待ください!!




2017年2月14日火曜日

iutest v1.16.1 をリリースしました

C++ テスティングフレームワーク iutest v1.16.1 をリリースしました。
Github: https://github.com/srz-zumix/iutest/releases
OSDN: https://osdn.jp/projects/iutest/releases/66838

変更点は以下の通りです。
  • 追加
    • XML_OUTPUT_FILE 環境変数に対応
  • 変更
    • IUTEST_BUILD を非推奨に変更し、IUTEST_MICROVER を追加
    • Wandbox の更新に合わせて iuwandbox を変更
    • iuwandbox: --list_compiler のようなオプション名中の _ を - に変更(_ 付きの旧オプションは将来のバージョンで廃止)
  • 修正
    • iuwandbox: -f,--compiler-option-raw で複数のオプションを適切にパースするように修正
    • バグ修正

今回は主にバグ修正とマイナーチェンジです。
注意としては、いくつか deprecated にしてます。
将来のバージョンで削除予定です。

(ちなみに Travis CI のテストが失敗してますが、これは Google Test の head がコンパイルエラーになるためです)
では。

2017年2月6日月曜日

[Jenkins]「ビルド手順の追加」にある処理を「ビルド後の処理」で実行したい場合の回避策


そっちにあるけど、こっちはない!!ってやつです。

まずやること
  1. 同じような Issue がないか探します。(https://issues.jenkins-ci.org/)
  2. 同じような Issue があったら vote します。
  3. 対応してもらえるのを待ちます祈ります。( ̄人 ̄)



















待てるかっ


Promoted Builds Plugin を使う
Promoted Builds Plugin を使ってこの問題を回避したいと思います。

Promoted Builds Plugin は本来は「ビルドを昇格させる」のに使います。
例えば、デプロイしたら昇格する、下流のテストが全部 PASS したら昇格する、とかですかね。

さて、Promoted Builds Plugin では Promote build が実行されるトリガーに「ジョブのビルド完了後」があります。
つまり、ビルド後の処理的な感じで実行できるのです。
「Promote builds when...」にチェックを入れ、「Criteria」の「Promote immediately once the build is complete」にチェックを入れます。(unstable でも実行したい場合は「Trigger even if the build is unstable」にもチェック)


そして、「Actions」には「ビルド手順」「ビルド後の処理」の中からアクションを選択できます。


ということで、「ジョブのビルド」→「ビルド完了」→「昇格ビルド」→「ビルド手順の処理」という流れで、「ビルド手順」にしかない処理も「ビルド後」にできちゃうのです!!

昇格成功すると★がつきます。


Post Build Script Plugin を使う
もっと直球に解決してくれるプラグインがあります。

それが、Post Build Script Plugin です。
名前からすると、「ビルド後の処理」で「スクリプト」を実行できるようなプラグインの印象を受けますが、このプラグインで実行できるのは bat/shell スクリプト、Groovy スクリプトだけでなく、「ビルド手順(build step)」の処理も実行できちゃうのです!!

Post Build Script Plugin をインストールすると「ビルド後の処理」に「Execute a set of scripts」が追加されるので、それを追加してください。


まさに、これ!!なプラグインですね。
最初は Promoted でできるよなーと思って調べ始めたのですが、こんな便利なプラグインがあったとは…
今後、Jenkins 構築するときには積極的にインストールしておきたいプラグインの1つになりそうです。


最後に
いかがでしたでしょうか?やっぱり探せばあるもんですね。
Jenkins ネタはまだまだ尽きないですな。

ではでは~