2015年11月30日月曜日

Magnum CI 始めました



つーことで、始めました。Magnum CI
Travis CIDrone.ioShippableWerckerAppveyorCircle CIChodeship、ときて8つ目のサービスです。

Magnum CI の特徴といえば、プライベートリポジトリがいくつでも無料で使える(今のところ)点と、Github や Bitbucket はもちろんのこと独自のリポジトリサーバーでも使える点でしょうか。

まぁ、今回は Python 2.7 系が使える CI サービスならなんでも良かったので、細かいことは省略。


サインアップ
Magnum CI では Github アカウントなど外部アカウントでサインアップできないので、普通に登録します。

プロジェクト作成
プロジェクト作成はこちらを参考にしました。



ポイントとしては、Github への WebHook, Deploy Key 登録です。
このへんは他の CI サービスだと勝手やってくれてたところなので、少し手間に感じましたが、
特に躓くことなく普通に登録するだけで OK でした。
(ここで正常にチェックアウトできるか Test Build しておくといいかもしれません。)

ビルド設定
設定は定番の YAML(.magnum.yml) ファイルに書くか Web 上で設定できます。
今回は Web 上で済ませました。


設定内容は上記サイトとほぼ一緒です。

画像では Build Step の各項目ごとに分けて書いてますが、分け方に特に意味はありません。
sudo apt-get -qq update -y
sudo apt-get -qq install libc6-i386 lib32gcc1 lib32stdc++6 -y unzip

wget http://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/nacl_sdk.zip
unzip nacl_sdk.zip
cd nacl_sdk
./naclsdk list
./naclsdk update
ls
find . -maxdepth 1 -type d -name 'pepper_*'
export NACL_SDK_ROOT="$(find `pwd` -maxdepth 1 -type d -name 'pepper_*')"
echo $NACL_SDK_ROOT
cd ../

cd projects/nacl
make

はじめに必要なものをインストールし、nacl_sdk.zip をダウンロード展開します。
naclsdk の機能を使って環境をインストール。構築された環境から pepper_* のパスを取得して NACL_SDK_ROOT 環境変数にセットします。
iutest の場合、projects/nacl フォルダに NACL 用の Makefile があるので、そこで make をしています。

結果はこんな感じです。
https://magnum-ci.com/public/ad50f16d4e6b5c8a578a/builds

バッジ
最後に CI サービス定番のバッジです。
これはプロジェクトの Stats で確認できます。

今回は以上。では~

2015年11月24日火曜日

Codeship 始めました

先週(ブログズミ: cpplint でコーディングチェック)にも書いたように、またしても CI サービスを使い始めました。
今度は Codeship です。



Codeship の無料プランはこんな感じです。

5 private リポジトリ、100回/月の private ビルド
OSS であればビルド無制限

サポート言語は以下


今回は cpplint.py を実行したいので Python が使えれば OK

プロジェクト作成
Sign Up したらプロジェクトを作ります。
Create a new project を押すと右のようなホスティングサービス選択画面が開きます。
目的のサービスを選択してください。
リポジトリのリストが表示されるので、目的のリポジトリを選択します。

つづいて、右のようなプロジェクト設定が出るので、それぞれ設定をしていきます。

「Select your technology to prepopulate basic commands」でターゲット言語を選択します。
今回は Python を使いたいのでそれを選択しました。

「Setup Commands」で環境のセットアップをします。
通常であれば、cpplint.py を使うためにダウンロードしたりするのですが、 iutest ではテスト用の Makefile で cpplint.py のダウンロードもするようにしているため、ここは空にしています。

「Configure Test Pipelines」でテストパイプラインを設定します。(無料枠だとパイプラインは1つまで、試用はできるみたいです。)
iutest では Makefile で cpplint がかけられるようにしているので、対象のディレクトリに移動して make するだけです。

cd test/cpplint
make

Makefile の中身はこちらから確認できます。
https://github.com/srz-zumix/iutest/blob/master/test/cpplint/Makefile

バッジ
最後に、CI サービス定番のバッジです。
バッジはプロジェクト設定の Notification にあります。


iutest/test/cpplint に貼り付けておきました。

2015年11月16日月曜日

cpplint でコーディングチェック

Google Style Guides のチェックツールとして cpplint.py があります。
今回はこれを使って iutest のコーディングスタイルをチェックしてみました。

cpplint.py の使い方
cpplint.py は github から取得できます。クローンしてもいいですし、cpplint.py だけダウンロードしても OK です。
https://github.com/google/styleguide

iutest の場合



1行の文字数やスペース、改行の入れ方などの報告のほかに、explicit を付けましょうとか const 参照にしましょうなどの報告も出ました。

チェック内容
チェックされる内容は以下のものがあります。

buildclass
c++11
deprecated
endif_comment
explicit_make_pair
forward_decl
header_guard
include
include_alpha
include_order
include_what_you_use
namespaces
printf_format
storage_class
legalcopyright
readabilityalt_tokens
braces
casting
check
constructors
fn_size
function
inheritance
multiline_comment
multiline_string
namespace
nolint
nul
strings
todo
utf8
runtimearrays
casting
explicit
int
init
invalid_increment
member_string_references
memset
indentation_namespace
operator
printf
printf_format
references
string
threadsafe_fn
vlog
whitespaceblank_line
braces
comma
comments
empty_conditional_body
empty_loop_body
end_of_line
ending_newline
forcolon
indent
line_length
newline
operators
parens
semicolon
tab
todo

これらはコマンドラインオプションで有効/無効を設定できます。

警告の除外
該当行にコメントで NOLINT と書いておくと無視してくれます。
using namespace matchers; // NOLINT

それか、--filter コマンドライン引数で無視指定ができます。
警告の末尾に [runtime/explicit] とか [whitespace/end_of_line] とかタグが表示されますので、該当のタグの先頭に '-' を付けると無効にできます。複数指定する場合は、カンマ(,) で区切ります。

cpplint.py --filter=-runtime/explicit,-whitespace/end_of_line

行の長さの設定
1行の長さも --linelength コマンドライン引数で指定できます。

cpplint.py --linelength=150

まとめ
cpplint.py (Google Style Guides)の規則が必ずしも良い、正しいわけではありませんが、1つの指標として役に立つと思いました。iutest でも一通りチェックしてみて、可読性に対してやポータビリティなどに対して改善できました。
というわけで、cpplint を CI で回すようにしています。

来週は cpplint を回している CI サービスの紹介をしたいと思います。
それでは、また来週~




2015年11月11日水曜日

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

C++ テスティングフレームワーク iutest v1.14.0 をリリースしました。
変更点は以下の通りです。

  • 追加
    • 大幅なリファクタリング
  • 修正
    • ::iutest::Range を Enum に対応
    • tools の python 3.x 系対応


今回は細かいバグ修正をして、v1.13.1 としてリリースするつもりでしたが cpplint などの対応をしていたら、影響の大きな変更が入ったため v1.14.0 としてリリースしました。
ですので、今回は新しい機能はありません。

cpplint はまたブログにします。それでは。

2015年11月9日月曜日

Circle CI 始めました

Circle CI については省略。
OSS なら 4 コンテナ無料で使えるようでしたので、iutest でも使ってみました。



したいこと
iutest では既に以下の CI サービスをそれぞれ目的別に使用しています。
CI目的
Travis CIgcc/clang でのテスト
ShippableWandbox で gcc/clang の各バージョンごとの syntax チェック
WerckerWandbox で gcc/clang の各バージョンごとの syntax チェック
Drone.ioコンパイル時間の指標
AppveyorVisual Studio でのテスト、Nuget デプロイ

今回は iutest 付属の python ツールのテスト用として Circle CI を使います。
テスト内容としては、様々なバージョンの python で実行して問題がないかをテストします。

circle.yml
Circle CI も Travis CI などと同じように YAML で設定をします。
今回の利用目的は、様々なバージョンでのテストということで、各バージョンごとにマトリックスを組もうと思ったのですが……そういったことは Circle CI ではできないようです。

rvm - Circle CIで複数Rubyバージョンを平行してテストする - Qiita

ただ、こちらに書かれているようにコンテナをパラレルで起動することで並列にテストすることができます。
それか、単純にバージョンを変更しながら直列に実行するかですね。

幸い github の public プロジェクトならば、4つまで無料でコンテナを使えるので、今回はパラレルで実行してみました。


prallel
まず、使用するコンテナの設定をします。
「Project Settings」 を開き、「Tweaks」 にある 「Adjust Parallelism」を開きます。

下のようにコンテナ設定画面になるので、4x まで選択します。

コンテナの設定は完了です。

次に、circle.yml の test の各処理に対して並列実行であることを追記します。
test:
  - python --version:
    parallel: true
コマンドの末尾に ':' を書いて「parallel: true」を記述します。
これでこのコマンドは各コンテナごとに実行されます。

pyenv
Python のバージョンを変えるのは pyenv で行います。
どのコンテナかどうかは、CIRCLE_NODE_INDEX でわかるのでこれで分岐します。

dependencies:
  pre:
    - |
      case $CIRCLE_NODE_INDEX in
        0) pyenv install -ks 2.7.10; pyenv global 2.7.10; $(pyenv which pip) install requests twilio; ;;
        1) pyenv install -ks 3.5.0;  pyenv global 3.5.0;  $(pyenv which pip) install requests twilio; ;;
        2) pyenv install -ks 3.4.3;  pyenv global 3.4.3;  $(pyenv which pip) install requests twilio; ;;
        3) pyenv install -ks 3.3.3;  pyenv global 3.3.3;  $(pyenv which pip) install requests twilio; ;;
      esac

コマンドの先頭の | は複数行に書くためのものです。

さて、ここでちょっと躓きました。
最初のころは以下のように machine で python version 指定していました。
machine:
  python:
    version: 3.5.0

そうすると、dependencies で pyenv global しても、test に入ったときには machine で指定したバージョンに戻ってしまっていました。
(理由はよくわからないけど、そういうもんだと思って) machine の記述は削除しました。


あとは、test で普通に python を使えば任意のバージョンで実行されます。
https://circleci.com/gh/srz-zumix/iutest

※ コマンドの末尾にコンテナ番号が {} つきで表示されます

まとめ
途中少し(いや割りと…)躓きましたが、複数バージョンでのテストができるようになりました!
Travis CI ほどではありませんが、分かってしまえば簡単でした。

あ、最後に CI サービス定番のバッジですが、
プロジェクト設定の Notifications > Status Badges で取得できます。
いやー Circle CI も便利ですなー

2015年11月2日月曜日

[TortoiseSVN] アイコンオーバーレイが表示されなくて困ったけど一応解決できたよ

TortoiseSVN のアイコンオーバーレイが表示されなくなってしまい、
非常に困っていたのですがなんとか解決できました。

この問題は検索したらたくさん解決方法がヒットします。例えば、

私の環境で起きていた問題も、ShellIconOverlayIdentifiers の数制限が原因でした。

対処方法
  • TortoiseSVN を新しいバージョンに更新する。
    新しいバージョンだと、ShellIconOverlayIdentifiers のプライオリティが上がって TortoiseSVN のアイコンが優先的に表示されるようになりました。
  • ShellIconOverlayIdentifiers レジストリから不要なものを消す。
    仕事のPCでは TortoiseSVN の更新ができない状況だったため、参考URL にもあるように
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers
    から不要なものを削除しました。
    (64bit だと HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node にも同様のキーがある)
    削除したら explorer を再起動。

これでとりあえず、解決できたのですが、
仕事PCの方はいつの間にかまたアイコンが表示されなくなってしまいました。。。
なんでかな?ともう一度レジストリを見ると、消したはずの DropboxExt が元に戻ってるではありませんか!

なんだか勝手に修復するみたいです。なんてヤツだ全く(いや、正しいと思います。でもいらないの。)

今度は、キーを削除しないでキーの既定の文字列を無効な文字列に書き換えてやりました
ただし、デタラメな文字列にしてもダメで、また復元されてしまいました。
上記リンク先にも書いてあるように、GUID を残しつつ無効な文字列にする必要があるようです。
例)MANUALLY_EDITED_{00000000-0000-0000-0000-000000000000}


簡単に DropboxExt のレジストリを書き換えるバッチファイルを書いたので、ご自由にお使いください。
(ただし、使用は自己責任でお願いします。バックアップを取るなりしてください。)
https://gist.github.com/srz-zumix/42121dc8dbabc651dc81


訂正。DropboxExt を書き換えても復元されてしまうので、上記方法は×でした。
なので、TortoiseSVN の方のレジストリキー名を変更して、DropboxExt より優先される名前に(先頭にスペースを2つ追加)しました。



それにしてもアイコンオーバーレイの上限数が少ないですよね。
これってなんとかできないんですかねぇ。根本的な解決ができたらいいのですが…



ともあれ、これでなんとか解決できたので今は良しとしておきます。
それでは。