2020年7月28日火曜日

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

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

変更点は以下の通りです。

* New
* GTEST_SKIP 対応
* IUTEST_*_NE_RANGE アサーションを追加
* IUTEST_*_NE_COLLECTIONS アサーションを追加

* Improved
* ::std::wstring_view / ::std::u16string_view / ::std::u32string_view 対応
* Variadic Templates 非対応コンパイラーでの型パラメータの型表示を改善

* Changes
* アサーションに operator << したときの出力を PrintToString したものと同じになるように変更
* iuwandbox: Wandbox 向けにサイズ圧縮したヘッダーをデフォルトで使用するように変更
* iuwandbox: 上記に伴いフルバージョンのヘッダーを使うオプション(--no-iutest-use-wandbox-min)を追加
* deprecated: iuwandbox: --iutest-use-wandbox-min
* Python2 のサポート終了

* Bug fixes
* C++20 で削除された basic_ostream::operator << に対応
* IUTEST_AP が同じ名前空間に複数定義できない問題を修正
* Google Test 旧バージョンとの互換性を修正
* その他いくつかの不具合を修正



では。

2020年7月21日火曜日

[技術書] 画像のフォーマットチェックを GitHub Actions でしてみた

技術書典8 で書いた本では結局電子書籍になったことと、スクリーンショットはあまり使わなかったことで、あまり画像のフォーマットは気にしてなかったのですが、次の執筆を始めてスクリーンショットを増やすつもりなので、ちゃんとするようにしました(特に DPI かな)。

というわけで、指定のディレクトリ配下の画像ファイルのフォーマット、DPI、ピクセル数をチェックする Action をリリースしました。


以下のように使用します。

name: GitHub Actions
on:
  pull_request:

jobs:
  example:
    runs-on: ubuntu-latest
    steps:
    - name: clone
      uses: actions/checkout@master
    - uses: srz-zumix/actions-book-image-check@master
      with:
        path: ./test/format
        formats: "JPEG, PNG" # default JPEG
        dpi: 300 # default 350
        pixel_limit: 1000000 # default 4000000

他にチェックしてほしい項目があれば PR なり issue なりいただければと思います。






2020年7月15日水曜日

[Travis CI] Segmentation fault したときにスタックトレースを出力する設定

テストがクラッシュして失敗したときの調査が手間だなーということで対応しました。

対応したときの PR がこちらです。
差分で見ると、なにを追加したか見やすいと思います。
[Travis CI] core dump by srz-zumix · Pull Request #288 · srz-zumix/iutest

以下、ポイントを説明していきます。

導入

gdb のインストール


コアダンプファイルの出力設定


まず、コアダンプファイルが出力されるように ulimit の設定をします。
また、iutest ではテスト時に複数の実行ファイルを実行するため、コアダンプファイル名に実行ファイルの名前もつけるようにしています。
(コアダンプファイルの中身から取れる気もするけど、これで十分)

クラッシュしたらスタックトレースを出力する


実行ファイルの名前解決
linux - Core dump file name truncated - Stack Overflow
%e だと 15 文字で truncate されてしまい、実行ファイル名が正しく取れなかったので以下のような対応をしました。
gdb で coredump 開くと実行ファイルがなんだったのか出力されるので、それを取得してます。


      for f in `find . -maxdepth 1 -name "core_x_*"`; do
        COREFILE=${f}
        EXECFILE=${f##*/core_x_}
        if [ ! -f "${EXECFILE}" ]; then
          EXECFILE=`gdb -c "${COREFILE}" -batch | grep -o -e "\./[A-Za-z_]*"`
        fi
        gdb -c "${COREFILE}" ${EXECFILE} -ex "thread apply all bt" -ex "set pagination 0" -batch
      done


出力例




最後に
最近はローカル環境で実行確認することも減ってきたので CI 上でデバッグできるようにしておくのは便利でいいですね。

今回は以上です。
では。

2020年7月5日日曜日

[CI][CodeReview] LGTM.com 始めました

LGTM.com ってのがあるのを知ったので使ってみました。


サインアップ~解析まで
サインアップから解析するまで一気に説明します。 まずはトップページの右上からログインします。 GitHub や BitBucket などのアカウントを使ってサインアップ可能になっています。
 
次に LGTM の GitHub App をインストールします。
リポジトリ選択では、解析したいリポジトリを選択、または全部許可にします。

LGTM.com に戻ると解析始まってると思います。

今回試したのは「自作 C++ テスティングフレームワーク」の iutest です。
C/C++ の場合はコードのビルドも必要なようですが、勝手に CMake のファイルを見つけて解析してくれました。



↓こちらが解析結果
他のレビュー系サービスや lint を使ってはいたのですが、案外問題がありました。

PR の解析
PR の解析はプロジェクトの↓が「Automated PR code reviews enabled」になっていると有効になっています。
無効になっている場合はボタンを押して有効にしましょう。

この状態で PR でレビュー箇所を修正したりするとコメントが付きます。

詳細はコメントのリンクもしくは、プロジェクトのところにある「Automated PR code reviews enabled」または、「Integrations」タブをクリックすると開きます。


メインブランチの解析
いろいろ問題が明るみになって早速修正、PR 上で修正確認できたのですが、マージ後の master ブランチの解析結果が変わらず、どうやったら解析されるのかなーと調べてたら、ドキュメントにちゃんと書いてありました。


LGTM.com は1日1回くらいの周期で新しいコミットを確認して解析するそうです。
なので、修正されるかどうかは PR で確認して、マージしたら気長に待つしかなさそうです。
チェック項目の抑制

LGTM.com で C/C++ のチェック項目はデフォルトで 140 あります。
iutest でいくつか抑制したい項目があったので方法書いておきます。

冒頭のツイート先の記事でも書かれていますが
(git push してすぐ lgtm に反映されるわけではない(数時間から半日くらいかかる)ので, 動作確認が手探りになってしまい時間がかかる)

lgtm.yml をコミットしてもすぐには反映されないみたいです。
ちょっとトライ&エラーが難しそうですが、
とりあえず、ドキュメント通りに書いておけば大丈夫なはず!

YAML で設定
YAML で ID ごとに exclude/include 指定ができます。
また、severity/tags でまとめて除外することもできるようです。
コメントで設定
C++ の場合は、「// lgtm[id]」を問題の行末に書きます。

Configuration のテスト
設定は web 上からテストすることも可能です。
Logs の右上に「Test analysis configuration」ボタンがあるので、そこを開くと任意のコンフィグを記述して解析を実行できます。
lgtm.yml をコミットしても即座に適用されないようなので、config はこちらを使ってテストすると良さそうです。



最後に
LGTM.com は CodeQL を使って解析をしているので、今まで使ってきた lint ツールなどとはまた違った解析結果が得られました。
こういった静的解析ツールは、手法の異なるいくつかのツールを併用したほうがより多くのインプットを得られるので、CodeQL ベースの解析の導入がまだであれば導入をオススメします。
また、本記事では触れませんでしたが、クエリは独自に書くことも可能です。
プロダクト固有のドメインをチェックしたりとかできそうです。

また、冒頭のツイートのリンク先でも記述されていますが、CodeQL の会社(Semmle)が GitHub に買収されていますので、今後は GitHub の機能とかでより使いやすくなったり、クエリが増えていくかもしれません。


今回は以上です。
では。