[Travis CI] after_success ステップ中の失敗はジョブの失敗にならない

Travis CI でなにか他のサービスと連携したり、デプロイしたりするときに、after_success で処理を書いているサンプルがちょくちょくあります。
after_success 自体は、ジョブが成功したときにだけ実行されるので、成果物に対してなにかするときに便利ではあるのですが、
実はこのステップ中の失敗は、ジョブの失敗にならず握りつぶされていることに気づきました。


そんなの知らないよーってことで、
なんと！一年以上 Codecov にカバレッジレポートがアップロードされてませんでした！！
「Codecov にカバレッジがアップロードされていない · Issue #233 · srz-zumix/iutest」

・失敗してるのに成功してるジョブ
https://travis-ci.com/srz-zumix/iutest/jobs/193873334




after_success に書く処理は失敗しても問題のないものにした方がいいな。と思いました。。。
解決策としては、（ベタに）ビルドステップに引っ越ししました。
travis-ci の issues でも似たようなやりとりがあったみたいです。
「after_success failure doesn't fail build · Issue #758 · travis-ci/travis-ci」

では。

Walterbot の「View log」 がすごく便利！

ブログズミ: [Wercker] Walterbot + Slack を試してみた

この記事を書いた時点では「View log」はなかったので紹介してませんでしたが、
これがすごく便利なので改めて紹介します。
（Walterbot については↑を参考にしてください）

View Log ボタンでエラーの周辺ログが見れる！！

「View Log」ボタンを押すと以下のようにログが見れます。


iutest の Wercker でのテストは
fused したコード（１ファイル化したもの）をさらに圧縮して（js の min.js みたいな） Wandbox に投げつけてコンパイル＆実行しているので、エラーがすごく見づらいのですが・・・

ともあれ、すごく便利なので Wercker 使いの方は、ぜひ Walterbot を使いましょう！！

[C++] g++ 9.1.0 で variant が valueless_by_exception にならないケースに遭遇した

iutest の開発をしていたら、variant が valueless になったときのテストが失敗するようになった。


テストコードはこれ。
valueless_by_exception と出力されるのを期待しているが、実際には 0.2 という空になる前の値を出力している。

{
    PrintToLogChecker ck("valueless_by_exception");
    ::std::variant<int, ::std::string, float> v = 0.2f;
    try
    {
        struct S { operator int() { throw 42; } };
        v.emplace<0>(S());
    }
    catch(...)
    {
    }
    IUTEST_SUCCEED() << ::iutest::PrintToString(v);
}

この valueless にするコードは、
https://ja.cppreference.com/w/cpp/utility/variant/valueless_by_exception からとってきたもので、今までは valueless になっていたのを確認している。

関連するコードをいじってはいないので、環境周りの違いだと思い確認したところ、g++ 9.1.0 では valueless にならないことを確認しました。
また、valueless な状態を作る方法を探していたら、
https://cpprefjp.github.io/reference/variant/variant/valueless_by_exception.html に AlwaysThrow でのサンプルがあったので、そちらを使って確認したところ g++ 9.1.0 でも valueless になりました。

gcc 9.1.0 [Wandbox]三へ( へ՞ਊ ՞)へ ﾊｯﾊｯ https://t.co/m7V6DImr9E

— ずみっくす :D (@srz_zumix) 2019年5月11日

(typo がひでぇ)

g++ 9.1.0 は前者のパターンは valueless ならず。
以前の値が残ってるみたいだけど、この挙動はなんかハマりそうな気がしないでもない。

— ずみっくす :D (@srz_zumix) 2019年5月11日

よって、テストコードとりあえず以下のように修正しました。

{
    PrintToLogChecker ck("valueless_by_exception");
    ::std::variant<int, float, AlwaysThrow> v = 0.2f;
    try
    {
        struct S { operator int() { throw 42; } };
        v.emplace<0>(S());
    }
    catch(...)
    {
        IUTEST_INFORM_TRUE(v.valueless_by_exception());
    }
    if( !v.valueless_by_exception() )
    {
        try
        {
            v = AlwaysThrow();
        }
        catch(...)
        {
           IUTEST_INFORM_TRUE(v.valueless_by_exception());
        }
    }
    IUTEST_SUCCEED() << ::iutest::PrintToString(v);
}

これはバグ？

cpprefjp も cppreference.com も、サンプルのコメントを読むと、確実に valueless な状態にはなるとは限らないように読み取れるのだが、（規格的に）これはそういうもんなのだろうか？それとも g++ 9.1.0 のバグなのだろうか？

一旦ここまでで記事公開させていただきます。
続報あれば、追記していきますmm

[Git] マージするときのリネーム上限とリネーム判定の抑制

最近、テスト結果を蓄積する試みをしていたら、git の挙動でハマったので備忘録として残しておきます。

git は意図的なリネームが可能ですが、意図しないリネームが発生したりすることがあります。
これは、リネームは削除と追加がまとまったもので（ほぼ）同じ内容のファイルが削除と追加（別名で）されたときに、git はリネームとして処理することがあります。
なので、こちらとしては望んでいない場合でもリネームとして扱われてしまうことがあります。
（ほとんどの人はこんなケースには遭遇しない気がするけど・・・）

で、なにが起きたかというと、
リネームが大量に検出されて、マージするときのリネーム上限に引っかかってしまいました。



というか、上限なんてあったんだ！という感じでしたが、git config merge.renameLimit で上限解放できるらしいです。

git config merge.renameLimit 9999

そもそもリネームじゃねぇっ！という場合は、merge.renames でリネーム処理を行わないようにもできます。

git config merge.renames false

たぶん、こういうケースにあたる人は少ない気がするけど、
merge.renameLimit と merge.renames config の紹介でした。
では。