[CI] Rocro で public リポジトリが使えるようになっていた！

Rocro で public リポジトリが使えるようになったので、iutest での本格的に運用を開始しました！
前回の紹介記事はこちら→「ブログズミ: [CI] Rocro 使ってみた」

今回は前回試してみたときからパワーアップしたところを紹介しつつ、設定したところも紹介します。

前回との差分

public リポジトリが扱えるようになった！

まずはこれですね。前回は private リポジトリのみだったので、Bitbucket に private なリポジトリを作って試していましたが、これで本格運用に入れます！

Cppcheck の結果が集計されるようになった

前回使ったときは、Cppcheck の結果はログからみる必要がありましたが、現在は他のツールと同じように集計されて見やすくなってます。

ファイルグレードが表示されるようになった

続いて目に入る変化としてファイルグレードがあります。
以下のようにレポートに表示されるようになってました。


これは解析結果からファイルを「Grade A」～「Grade F」に評価したもののようです。
指標の１つとして使えそうです。

バッジにファイルグレード版が追加されました

最後に、ファイルグレードの結果がバッジとして使えるようにもなってました。
こちらは通常のバッジと同じく、「Settings」にある「Badges」から使うことができます。

rocro.yml に Cppcheck の設定を書く

Cppcheck の解析結果が表示されるようになりましたが、インクルードパスなど適切に設定しないとあまり意味のないものになってしまします。
ツールなどへの設定は rocro.yml で指定できるようなので、設定してみました。

参考：Cppcheck · INSPECODE

	inspecode:
	cppcheck:
	options:
	--enable: all
	-I: include
	-D:
	IUTEST_HAS_CLOCK=1
	_WIN32=1
	_MSC_VER=1700
	-U:
	__GNUC__
	__clang__
	__CYGWIN__
	__APPLE__
	--platform: win64
	--inline-suppr:
	--suppress:
	syntaxError
	--max-configs: 20
	#--force:
	ignore:
	test/spi_tests_decl.cpp
	thresholds:
	num-issues:
	#information: 0
	style: 0
	performance: 0
	portability: 0

view raw rocro.yml hosted with ❤ by GitHub

ほかにも環境変数などの設定もできるようですが、まだ「EXPERIMENTAL」、実験中みたいです。

使ってみて気になったこと

• --force オプションつけるとタイムアウトしてしまう
  -D/-U オプションで解析ブランチを減らすか、--max-configs で深さを指定することで回避するしかなさそう
  
• 並列オプションが使えない
  -j オプションほしいですね。
  
• suppress に syntaxError を指定したが一部の除外されないものがある
  これは Rocro 側ではなく cppcheck の問題だと思います。（ローカル環境でもそうだったので）
  syntaxError で報告されてるけど、内部的にエラーIDが異なってたりするのだろうか？
  
• ログの詳細がみたい。Cppcheck の解析中のログも見れたら設定の参考にできるな、と思った。
  

最後に

iutest での本格運用を開始しましたし、まだ使っていないツールもあるので、
またノウハウが蓄積したらブログにしたいと思ってます。

Supported Tools · INSPECODE


scan-build があるから Semaphore から Rocro に引っ越しできそう
Rocro のさらなる進化に期待してます。
今回は以上です。では。

CloudBees Jenkins Advisor をインストールしてみた

「第11回 Jenkins勉強会」で知った CloudBees Jenkins Advisor をインストールしてみました。
勉強会参加報告はこちら→（ブログズミ: 「第11回 Jenkins勉強会」に参加してきました）

SignUp してインストール

「USE IT FREE NOW!」からサインナップします。


完了すると以下のような画面になります。
（Trial Period Overなのは、むかーし使ってたことがあるから。前と大分変わりましたね）


以前に登録していたので SignUp 手順が確認できませんでしたが、必要になってくるのはアカウント名とパスワードなので、それがあれば問題ありません。

プラグインインストール

プラグインのインストールは普通に Jenkins のプラグイン管理からできます。
「CloudBees Jenkins Advisor Plugin」があるので、いつもどおりインストールしましょう。

セットアップ

「Jenkins の管理」を開くと以下のようなメッセージが出ています。「Connect Now」をクリックしましょう。


接続設定画面が開くので、先程登録した「CloudBees」のアカウントメールアドレスとパスワードを入力します。
「Advanced configuration」がありますが、とりあえず使いたいだけなので特に設定せずに「Connect account」します。


すると、アカウントメールアドレスに以下のようなメールが来ます。
レポートが１日ごとに来るようなので、１日待ちましょう。

レポート

なんか出てますね・・・
とりあえず今回はインストールして使ってみただけなので、ゆくゆく調べながら対応していきますか。

最後に

Jenkins Advisor についてはこちらの CloudBees のブログにも書かれています。
Jenkins AdvisorでJenkinsのダウンタイムを防ぐ | Cloudbees Jenkins Solutions
ロードマップによれば、閉じられた環境の Jenkins の診断対応やダッシュボードの追加がされるようです。
こちらにも期待しつつ、インストールした状態でしばらく使ってみようと思います。

では。

「第11回 Jenkins勉強会」に参加してきました

どうも僕です。仕事が始まって１週間。こちらでの生活にも慣れてきました。
そんなこんなで「第11回 Jenkins勉強会」に参加してきました。
東京来て一発目の勉強会！久しぶりの参加報告って感じですね。

今回の講演は３つ + LT ３本立て。

「初めての自動テスト meets Jenkins」

最初は「初めての自動テスト ―Webシステムのための自動テスト基礎」を翻訳された玉川紘子（@nkns165）さんの講演。

原著者がアジャイルサムライを書いた人と一緒とか、CI の章がないが CI があっての自動テスト（あるの当たり前）とか、翻訳こぼれ話とか、興味深い話が聞けました。
自分も本に関わってみたいなぁー

発表資料を公開しました！ https://t.co/i1nyvGBxwq #jenkinsstudy

— Hiroko T (@nkns165) 2017年11月8日

「Jenkins World 2017 の報告」

2つ目は Jenkins World 2017 で「Most Valuable Advocate」受賞の中村知成（@ikikko） さん！
（そのへんは @ikikko さんのブログへ）

#jenkinsstudy 先程の発表資料「Jenkins world 2017の報告」はこちらです https://t.co/RDeW036pdm

— ikikko (@ikikko) 2017年11月8日

Jenkins Advisor はじめて知りました。さっそく使ってみようと思いました。

Jenkins world の動画はここかな？
https://www.youtube.com/user/CloudBeesTV

「Jenkins PipelineとBlue Oceanによる、フルスクラッチからの継続的デリバリ」

最後は川口さん！

↓は今回の講演と（たぶん）同じヤツ

Groovy でなんでも書かない。複雑なデプロイ処理は外部に逃してコールするだけ #はい #jenkinsstudy

— ずみっくす★ (@srz_zumix) 2017年11月8日

#はい

when で任意ブランチでのみ stage できるっぽいので、iutest のパッケージビルドを Jenkinsfile にお引っ越ししようと思いました。

---

LT

ここから LT

遠くの"計画"よりも今日の"CD"(継続的デプロイ)

今からLTする資料はこちらになります！
遠くの"計画"よりも今日の"CD"(継続的デプロイ) #jenkinsstudy https://t.co/WpdkkAsWnY

— みうら かずひと (@kazuhito_m) 2017年11月8日

タミヤ カムプログラムロボット工作セットで作るXFD

今日のLT資料です。 https://t.co/8ACIxed5GB#jenkinsstudy #tamiya

— Kiyotaka Oku (@kiy0taka) 2017年11月8日

開発者(個人)のためのJenkins 運用編

LTの資料です #jenkinsstudy
開発者(個人)のためのJenkins 運用編https://t.co/qb1pm9Ch9P

— yasuhiroki (@duck_yasuhiroki) 2017年11月8日

感想

参考になる話、知見、情報と持ち帰るものが予想以上にあってよかった。
LT はホントいつも面白いし、すごい！
懇親会でも色々いいお話聞けたのでとっても大満足。

最後に、テクマトリックスさん、スタッフのみなさん、そして講演者の方々、ありがとうございました～

[Appveyor] イメージを環境変数で指定する

今回は Appveyor で環境変数を使ったイメージの指定を紹介します。
iutest のテストでイメージごとにそれぞれ異なる環境変数を設定したかったときに、この方法に行き着きましたのでそれの紹介です。

テストではよくマトリックスを組んで複数の環境でテストをすることが多いと思います。
Appveyor なら、イメージが複数用意されているので、それぞれでテストを実行することになります。その場合はイメージを複数指定すれば OK です。
さらに環境変数を列として、イメージ×環境変数のマトリックスも組むこともできます。
さきにこちらの方法を紹介しておきます。

イメージと環境変数のマトリックス

まずイメージは「SETTINGS」「Environment」の「Build worker image」で複数設定することができます。
指定したイメージの分だけ、ジョブが実行されます。


さらに、同じく「Environment」の「Environment variables」で環境変数を指定できます。
「Add variable」だと、各イメージで共通の環境変数が設定されますが、「Add build matrix group」では環境変数のマトリックスを作成できます。


グループを追加すると「Environment variables - 1」「Environment variables - 2」のようにグループが増えていきます。
それぞれ「Add variable」から環境変数を設定できます。



テーブルにするとこんな感じです。

ENV_M value	Visual Studio 2015	Visual Studio 2017
Environment variables - 1	1	1
Environment variables - 2	2	2

Visual Stduio 2015/2017 のイメージそれぞれに対して、ENV_M が 1 と 2 のジョブが実行され、計4つのジョブが実行されます。

iutest でやりたかった構成

さて、これに対して iutest でやりたかったことはこうです。

ENV_M value	Visual Studio 2015	Visual Studio 2017
Environment variables - 1	1	×
Environment variables - 2	×	2

※×印はジョブを実行しないという意味です
上と合わせて書きましたが、わかりやすくするとこうです。

	Visual Studio 2015	Visual Studio 2017
ENV_M value	1	2

つまり、マトリックスにしたいわけではなく、イメージ対して一意な環境変数を設定したいわけです。



これができないか調べていたら、イメージのマトリックスを使わずに、「APPVEYOR_BUILD_WORKER_IMAGE」環境変数でイメージの指定ができることを知りましたので、これで解決しました。

イメージを環境変数で指定する

環境変数マトリックスでイメージを指定するので「Build worker image」は空にします。
次に、「Add build matrix group」で環境変数のグループを作成し、環境変数名「APPVEYOR_BUILD_WORKER_IMAGE」でイメージの名前を設定します。


これで実行すると「Environment variables - 1」のときだけ、イメージ設定が上書きされます。


環境変数が変わっただけでイメージが変わってないかもしれないので、以下のコマンドで確認しました。


結果、このようにイメージが変わっていることを確認。

まとめ

イメージに対して環境変数を別途指定したい場合は、環境変数のマトリックスと APPVEYOR_BUILD_WORKER_IMAGE を使うと実現できます。
イメージ×環境変数のマトリックスを組みつつ、イメージに対して個別で一意な環境変数をセットしたい場合は、APPVEYOR_BUILD_WORKER_IMAGE 環境変数を参照して判断するのが良さそうです。

マトリックス化する予定があるなら、最初から APPVEYOR_BUILD_WORKER_IMAGE を参照して分岐させるほうがいいかもしれないです。
このへんは好み、かなぁ・・・
ともあれ、APPVEYOR_BUILD_WORKER_IMAGE は ReadOnly じゃなくて Write もできるってことを覚えておくと今後役に立つかもしれません。（たぶん）


今回は以上です。では。

初出社

本日、初出社でございます。
報告記事でブログ更新回数を稼いでいますが、ここ１ヶ月ほどやることが多くて全くもってプログラムをしてませんでした。（引越前の駆け込み観光とか引越後の観光とか）インプットがないとアウトプットもなかなかないわけで…

休暇も終わってこれから新天地での生活ルーチンが構築されていくわけですが、これまで通り趣味プロやブログを書く時間を作っていきたいと思います。（早速この記事は通勤中に書いてます）

では、今後ともよろしくお願いしますm(__)m