2017年4月17日月曜日

[CI] Codefresh を始めました



Codefresh というサービスを知ったので使ってみました。
(ちょうど Google Test の互換性テストを Travis CI から引っ越ししようかなと思っていたので、タイミングが良かった)
Codefresh は Docker 対応を売りにした CI サービスのようです。
が、個人的には Docker 使ったことがないですし、iutest のテストでも使う必要がないので、全くもって Codefresh の旨味を使うことがないです。
なので、Docker 的な話は公式サイトや以下のような記事を参照してくださいm(__)m


ともあれ、そこに CI サービスがあれば使うおじさんなので(もはや、手段と目的がごっちゃになってますが)始めて行きましょう。

Pricing
ちなみに Codefresh も (オープンソースであれば) 無料から始めることができます。
フリープランでは並列ビルドなし、Environment も1つだけです。


Environment
Codefresh ではビルドした Docker イメージ(Service)からコンテナを実行することができます。
この実行環境が Environment です。
フリープランだとこれが1つに限定されます。
今回は特に使わないので、省略します。

アカウント作成
アカウント作成をしていきましょう。
最初にログインアカウントとして Github or Bitbucket の選択をします。(今回は Github を選択)


権限要求されるので問題なければ許可しましょう。


アカウント名やメールアドレスが自動で入力されます。変更が不要であれば「NEXT」をクリック。


このあとアンケートが少しありますが、飛ばしてしまっても構いません。


これでアカウント作成は完了です。

サービスの作成
Codefresh では他の CI サービスでいうジョブのことをサービスと表現します。
やることは他の CI サービスとほとんど同じです。

まずは、リポジトリを選択しましょう。



リポジトリを選択したら、サービスを何で構築するかを「YAML」「Dockerfile」「Template」から選択します。
今回は「TEMPLATE」を選択。


プラットフォームの選択画面になるので、条件に合うものを選択します。
今回は「Ubuntu」を選択。


Dockefile が作成されます。
編集はあとでもできるので次に進んでしまって問題ないです。


これでサービスが作成できました。
「BUILD」ボタンを押して実行してみましょう。
テンプレートから変更していないので成功するはずです。



テスト
Codefresh では、作成した Docker image に対してテストを実行することができます。
テストは「Unit Test Script」に記述します。


特に難しいことはなく、コマンドを書いていくだけです。
これで iutest の CI 環境としては完成です。
Codefresh の特徴を活かすのであれば、このあと Launch するのがいいのでしょうが、iutesst はサービスではないのでここまでです。

最後にお約束のバッジ
バッジは「General Settings」のバッジをクリックすると Markdown テキストなどが得られます。




今回は以上です。では。

2017年4月10日月曜日

[Docker] 始めてみたけど躓きまくってるので備忘録として残しておくよ

注意:有益な情報はありません
完全な個人用メモです。
それでも引っかかる情報はあるかもしれませんが、今すぐバックすることをおすすめします。
自分でも調べてて感じましたが、変化が激しいので古い情報はすでに当てはまらないことがあります。
検索ツールで期間を絞ったり、バージョンを絞ったりして調べることをおすすめします。

前提条件

* Windows + Docker Toolbock
* Windows 10

VBoxManage.exe: error: Failed to create the host-only adapter

Vagrantでのhost-only adapterのエラーを回避する方法 on Windows10 - OSSを触りながらつぶやく日記

Failed to open/create the internal network 'HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter

VirtualBoxでHost-Only Ethernet Adapterが原因でVMが起動しない時 | ぅゎょぅι゛ょっょぃ

ssh
docker-machine ssh default


ホストの作成からやり直す
"Docker Quickstart Terminal" ショートカットを使った場合、既にホストが存在すれば作成をスキップします。
なので、設定とか変えてもう一度ホストを作成しなおしたい場合は、
docker-machine rm default
としてからショートカットを起動します。


コンテナの一括削除
docker rm `docker ps -a -q`

不要になったイメージ・コンテナの削除
docker image prune
docker container prune
docker system prune


server misbehaving.
$ docker run hello-world
time="2017-02-24T10:07:02+09:00" level=info msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows"
Unable to find image 'hello-world:latest' locally
C:\Program Files\Docker Toolbox\docker.exe: Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 10.0.2.3:53: server misbehaving.
See 'C:\Program Files\Docker Toolbox\docker.exe run --help'.

/etc/resolv.conf に nameserver 8.8.8.8 を追加する

$ docker run hello-world
time="2017-02-24T10:18:53+09:00" level=info msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows"
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
78445dd45222: Pull complete
Digest: sha256:c5515758d4c5e1e838e9cd307f6c6a0d620b5e07e6f927b07d05f6d12a1ac8d7
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://cloud.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/engine/userguide/


Error response from daemon: Get https://registry-1.docker.io/v2/: Method Not Allowed
いろいろやってるうちに、こんなエラーがでるようになった。
素の host を作り直したら、server misbehaving. も含めてなぜか解決した…
解決した理由がよくわからない…

No space left on device
boo2docker だと、tmpfs がメモリにマウントされるらしいので virtualbox のメインメモリを増やしてあげます。
docker-machine create に --virtualbox-memory オプションを指定すればいいみたいです。
ショートカットから start.sh を実行している場合は、一度 default を削除して、start.sh の create コマンドを実行しているところに、--virtualbox-memory を指定します。
もしくは、default を stop して VirtualBox マネージャーから設定を変更すれば OK です。

TMP じゃなくて普通にディスクサイズが足らない場合は、--virtualbox-disk-size オプションを指定するか、同様にマネージャーで容量増やしてください。
※ start.sh で docker-machine create -d virtualbox default してるだけなので、一度削除してから --virtualbox-disk-size つけるのが楽そうでした。


docker run -v > Error response from daemon: invalid bind mount spec
ホストディレクトのパスは絶対パスなので、c:\ とか書くと上記エラーになる。
Windows のパス形式 (c:\hoge) だとダメなので、/c/hoge のように書く必要があります。

PowerShell (Windows) で Docker コンテナにホストディレクトリをデータボリュームとしてマウントする際に pwd 相当のことをしたい - ひだまりソケットは壊れない

※ docker cp のときは Windows 形式

ホストとコンテナ間でのファイルコピー

docker cp from to

コンテナのパスは コンテナ名:パス のように書く。
e.g.
docker cp aa237:/path/to/dir hoge

コンテナ名は docker ps で確認できる。
ハッシュにしたくない場合は、run するときに --name オプションを付けると良い。

docker run 時に環境変数を設定する
dockerのコンテナ実行時にLANGなどの環境変数を設定する方法 - Qiita
docker run -e HOGE=hoge

ストレージの保存場所を変更する
MACHINE_STORAGE_PATH 環境変数にパスを設定すれば OK

Looks like something went wrong... Looking for vboxmanage.exe
VBOX_MSI_INSTALL_PATH 環境変数がなくなってないか確認する。(VirtualBox を更新すると消える?)



SVN: can't convert string from 'utf-8' to native encoding
Docker ではなく svn co したときのエラーですが、日本語ファイル名が含まれていると発生します。

以下を Dockerfile に追記して対応しました。
参考:「オデの日記@WEB系: svnでどんなに頑張っても"can't convert string from 'utf-8' to native encoding"エラーが治らない

RUN localedef -f UTF-8 -i ja_JP ja_JP.utf8
ENV LC_CTYPE ja_JP.utf8


最後に
一応これで docker を使い始めることができるようになりました。
が、Dockerfile 書きながらイメージを作っていくと、あれが足りなかった、あれが間違っていたと、何回もやり直しして想像以上に構築に時間がかかってしまっています。
なにかうまいやり方がある気がするのですが、知識不足が非常にネックになっている状況ですね。
どこか勉強会とかに行ったり、聞いたりするのがいいのかもな~
ということで、雑にまとめましたが、ここで書きなぐりを一旦終えます。
以上。




2017年4月3日月曜日

Doxygen の特殊コマンドの typo チェックをする

ソースコードのドキュメント生成に Doxygen はよく使われていると思います。
/**
 * @ingroup VALUE_PARAMETERIZED_TEST
 * @def     IUTEST_INSTANTIATE_TEST_CASE_P
 * @brief   パラメータテストインスタンス化マクロ
 * @param   prefix_         = インスタンス名
 * @param   testfixture_    = テストフィクスチャ
 * @param   generator_      = Range, Bool, Values, ValuesIn, Combine, Pairwise ...
 * @param   ...             = Param name generator function (option)
*/
このようなコメントを記述することで自動的にドキュメントを生成する仕組みですが、
この @ から始まる特殊コマンドをよく typo してしまうことがあるので CI で簡単にチェックできるようにしてみました。

チェック用の .mk がこちら

make -C DoxygenCommandCheck.mk ROOT=path/to/dir

のように使用します。

自作の C++ テスティングフレームワークの iutest で実際に検出した結果がこちら。



やっぱり typo してましたね…
生成されたドキュメントを見ても、気づきにくいところだと思うので是非活用してみてください。
(しかし、なんで make で書いたんだろ… .sh で良かったのでは…)

2017年3月28日火曜日

[自動化] ニコニコ静画で削除されたクリップを通知

クリップしたものの削除されてしまった投稿は、クリップから削除するようにしているが、全クリップ・全ページを目視するのは面倒なので、自動化しました。

環境は Semaphore + Python + BeautifulSoup で、ソースコードはこちらです。
https://github.com/srz-zumix/niconico-seiga

Semaphore では定期実行が可能なので、こちらを利用しました。
毎日チェックして削除された投稿があるとメール通知が飛んできます。


自動削除までやったらもっと楽になりますが、
これでも、どのクリップのどのページの投稿が消えたかすぐわかるので、随分楽になります。
自動化素晴らしい!
今回は以上です。では。

2017年3月21日火曜日

[CI] Semaphore 始めました

Semaphore は、既に2016年の3月から使っていたのですが、ブログにしてませんでした。

(いつのまにか変なおっさんが・・・)

ブログズミ: 無料で使える CI サービス比較」などで紹介したこともありますが、その当時はまだ使ってませんでした。
現在は iutest に対して clang analysis (scan-build) を行う CI として利用しています。
また、定期実行ができ Bitbucket 連携、private も Free プラン内で利用可能な点から他のことでも便利に使わせてもらっています。
今回はサインアップから概要程度の内容ですが、その辺の話もそのうち紹介したいと思ってます。

Semaphore
これまでに様々な CI サービスを紹介してきましたが、
Semaphore は Circle CI と同等の速さ(Travis や Codesihp よりは速い)と並列実行、シンプルが売りらしいです。
(シンプルだとは思ってるけど、速さとかは気にしたことないので実感ないなぁ)
個人的に便利だと思っているのは前述した、定期実行と Free プランで private リポジトリも扱える点です。


Pricing
さて、その Pricing ですが、基本的には有料です。
ただし、OSS であれば Free (2並列まで) で使えます(よくあるパターンですね)。また、Private リポジトリでも 100 job/月 までなら Free で使えます。

アカウント作成~プロジェクト作成
Semaphore は他の CI サービスと違い、Github などの外部アカウントでのサインアップがありません。
トップページの右サイドのところから、アカウント名、メールアドレス、パスワードを入力して、「Create Free Account」をクリックします。



入力したメールアドレスにメールが送られてくるので、
そちらのリンクを開いたら登録完了です。




つづいて、プロジェクトを作成していきます。
最初に Github か Bitbucket かを聞かれるので、選択してください。
初回はアカウント連携をする必要があると思いますので、適宜対応してください。


次にリポジトリを選択。


ブランチを選択。


リポジトリの解析が始まるので終わるまで待ちます。


解析が終わるとプロジェクトの作成が完了です。
あとは、何をさせるかを設定していきましょう。


設定に関しては特に説明するようなこともないので、省かせて頂きます。

最後に
Semaphore はシンプルに使えていいなぁーって感じくらいで、今回の紹介ではあんまり良さは伝わらないんじゃないかなと思います。
ただ、冒頭でも書いたとおり、Bitbucket + private が無料プランでデキルのが一番のメリットではないかと思います。
このへんも紹介したいところですが、まだまだ作業中な状態なので、もうちょっとお待ちください。定期実行の活用例は近いうちに紹介できると思います。

では。今回は以上です。









2017年3月13日月曜日

[MSBuild] コード分析警告をエラーとする

Visual Studio コード分析機能については省略。
こちらの機能が無効な状態で SCM 管理されている場合、MSBuild で /p:RunCodeAnalysis=true /p:EnablePREfast=true をつけてビルドするとコード分析が有効になります。
Jenkins でこれを実行して、警告集計している場合は、警告プラグインの設定でジョブを失敗にしたり、不安定にしたりできるので問題ないのですが、CI サービスを使っていると Warning は成功となってしまいます。(exit code 0)
実際、自作 C++ テスティングフレームワークの iutestAppVeyor でコード分析させてましたが、ずーーーっと警告を無視してました…





これを解決する方法はとても簡単です。
MSBuild のコマンドラインオプションに /p:CodeAnalysisTreatWarningsAsErrors=true を追加してください。これで、コード分析警告をエラーとして扱うようになります。



今回は以上です。

2017年3月7日火曜日

[Wercker] Walterbot + Slack を試してみた



Wercker に Walterbot というのがあったので使ってみました。
画像のとおり、Slack と連携する bot のようです。

Slack のセットアップ


まず、Slack のチームを作っておく必要があります。
仕事で使ってますが、個人用になかったので今回作りました。
iutest-team.slack.com
といっても、一人だし何もしゃべってませんが…

Walterbot セットアップ
というわけで、一人で寂しいので Walterbot をチームに加えたいと思います!
こちら(http://www.wercker.com/walterbot)のセットアップ手順に従ってやれば問題なくできると思います。


手順は3つです。
まずは、「Add to Slack」ボタンを押して Walterbot をチームにインストールします。
参加させたいチームを入力、認証をしてください。
  

これでインストール完了です。


特に問題がなければ、Slack に Walterbot さんが Join していると思います。



Token 作成と登録
続いて、Walterbot が CI ステータスを喋れるようにトークン作成と登録を行います。

トークンの作成は Wercker の Web ページで行います。
アカウントの「Settings」から「Personal Tokens」を開いて、「Name」に適当な名前をつけて「Generate」するだけです。

Generate するとトークンが出来上がるのでコピーしておきましょう。



ここからは Slack での作業になります。
先程作成したトークンを使って以下のコマンドを実行します。
/walter register <token>


通知設定
連携のための設定が完了しましたので、最後に通知設定をしていきます。
通知設定は subscribe コマンドを使います。まずは使い方を聞いてみます。
/walter subscribe help

Use `/walter subscribe` to get notifications on passed/failed runs
In order to receive notifications for runs on apps you can use:
`/walter subscribe to [owner/app name] by [me, wercker username or any] on [fail, pass or all]`
Get a list of all subscriptions via:
`/walter subscribe list`

ヘルプによれば、owner また app に対して、誰が、失敗 or 成功またはそのどちらかによって結果を通知してくれます。
今回は試しに iutest に対して any/all で設定しました。
/walter subscribe srz-zumix/iutest any all


テストが成功するとこんな感じで教えてくれます!



通知設定を解除するときは、/walter unsubscribe コマンドを実行すると下のように解除UIが表示されます。


最後に
今回は使ってみた程度ですが、Slack をよく使っているチームにはうれしい機能ではないでしょうか?
先週の Workflows に引き続き、Wercker の機能を紹介しましたが、今後もっともっと便利になっていくことを期待してます。






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 ができるとすごく嬉しいですが、なくてもすごく便利に使えると思うのでオススメです!
今回は以上です。
では。