2016年8月30日火曜日

このブログのアドセンス収益が最小支払額に到達しました

このブログを始めて約６年で、アドセンスの最小支払額に到達しました。
お小遣い稼ぎ程度に設定をしておりましたが、ようやくリターンが得られました。長かったですね。
こういったので生活している人は大変だなぁと思った。


さて、せっかくなのでここに至るまでのレポートを載せておこうと思います。



赤色がページビューで、青色が収益です。
ページビューは右肩上がり、収益は（先月が異常に高かったですが）、年を追うごとに少しずつですが上がってる感じでした。

さらに、直近一年間の月平均
ページビュー表示回数クリック数収益
9,31817,9804￥309

月平均約300円の収益なので、1年で3600円。3年くらいしたら、また最小支払額に到達する感じですね。
収益を上げることがこのブログの目的ではありませんが、モチベーションの１つとして今後もやっていきたいと思います。どうぞ今後ともよろしくお願いします。
投稿者 時刻: 0 件のコメント:
ラベル:

2016年8月22日月曜日

[Jenkins] Warnings Plugin の新規警告の計算について

Warnings Plugin には警告の総数もしくは新規警告数に応じて、ステータスを変更する機能があります。

この機能を使って、警告が残っていたら不安定（黄）にすることが多いのですが、
最近になって、警告が増えたら（新規警告があったら）不安定にするような使い方を始めました。
そうしたらものの見事にハマったので備忘録として書き残しておきます。

新規警告がないにも関わらず不安定になってしまう！！
そんなことが起こってました。
再現ジョブを作ったのでそちらで確認していきます。

まず、ビルドするソースコードはこちら
1
2
3
4
int main(int argc, char** argv)
{
    return 0;
}
なんのへんてつもないコードです。
これを g++ -Wall -Wextra でビルドするジョブを作成します。

これを1回成功させておきます。
このときの警告は2件です。


続いて、新規警告が1件でもあったら不安定するように設定を変更します。
そして、ソースコードも以下のように書き換えます。
1
2
3
4
5
int main(int argc, char** argv)
{
    int x;
    return 0;
}

これを実行すると、結果は新規警告1件により不安定になります。
このとき警告の総数は3件です。


ここまでは、問題ありません。
次が問題です。

もう一度ジョブを実行します。
今度はソースコードを変えてませんので、警告数は3件のままで新規警告も 0件 のはずなので、成功になるはずです。ところが、実際には不安定になってしまうのです。なぜ？！



なぜなのか
ログを見てみましょう。

なぜか新規警告が1件と出力されています。
ビルド結果ページを見ると 0件 なのに？

どうやら、Warnings Plugin で見る新規警告は、最後の成功ビルドから見ての新規警告だったようです。
（ソースコード変更後の警告数は3件なので、成功時の警告2件からみると1件増えたように見える）
ログにもちゃんと
[WARNINGS] Computing warning deltas based on reference build #9
と書いてありました。

前回のビルドから見て欲しい
簡単でした。
「Use previous build as reference」にチェックを入れるだけです。


この状態でもう一度ジョブを実行すると、意図通り成功になりました！


ログもこの通り、ちゃんと１つ前のビルドを参照しているようです。

最後に
「Use previous build as reference」とか、「Only use stable builds as reference」とか、
説明が英語だったのでスルーしてましたが使いどころが分かりました。
また、どういう挙動をしているのか少し分かったことで、通知の仕方の幅が広がりました。
（成功時の警告数を下回るまで不安定するのもアリだと思った）

今回は以上。
では。


投稿者 時刻: 0 件のコメント:
ラベル: ,

2016年8月9日火曜日

[Jenkins] Pipeline Plugin を使ってみた

Jenkins LTS も2系がリリースされたことですし、そろそろ本格的に移行を始めないとまずいよなーということで構築中です。


まずは、普段一番よく使っている svn のコミットを git にプッシュするジョブを移植しました。
（本当は逆がいいんだけど、そのうち開発フローを見直す予定…）
できたのがこちら。ちょっと詰まったところだけ解説していきます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
node {
    withEnv(['SVN_LOGFILE=..\\svnlog.txt']) {
    stage 'make commit message'
     
    env.SVN_REPO = SVN_REPO
    env.ISSUE_NUMBER = ISSUE_NUMBER
    if( CommitMessage == "" ) {
        bat '''
        for /f "tokens=1,2" %%i in ( \'svn info http://svn.osdn.jp/svnroot/iutest/%SVN_REPO%\' ) do (
          if "%%i" == "Revision:" (
            call :setr %%j
            goto :EOF
          )
        )
        goto :EOF
        :setr
        chcp 65001
        SET LANG=ja_JP.UTF-8
        SET REVISION=%1
        if exist %SVN_LOGFILE% del /F %SVN_LOGFILE%
        for /f "skip=2 eol=- tokens=*" %%c in ('svn log http://svn.osdn.jp/svnroot/iutest/%SVN_REPO% -r HEAD') do (
            @echo %%c >> %SVN_LOGFILE%
        )
        if "x%ISSUE_NUMBER%" == "x" (
            @echo update r%REVISION% >> %SVN_LOGFILE%
        ) else (
            @echo update r%REVISION% #%ISSUE_NUMBER% >> %SVN_LOGFILE%
        )
        '''
    } else {
        env.COMMIT_MESSAGE = CommitMessage
        bat '''
        chcp 65001
        SET LANG=ja_JP.UTF-8
        echo %COMMIT_MESSAGE% > %SVN_LOGFILE%
        '''
    }
    bat '''
    @echo off
    chcp 65001
    SET LANG=ja_JP.UTF-8
    type %SVN_LOGFILE%
    '''
 
    stage 'git clone'
    deleteDir()
    git branch: 'develop', url: 'git@github.com:srz-zumix/iutest.git'
 
    stage 'svn export'
    bat 'rm -rf *'
    bat 'svn export --force http://svn.osdn.jp/svnroot/iutest/%SVN_REPO% ./'
     
    stage 'git commit'
    bat 'git add .'
    bat 'git commit -a -F %SVN_LOGFILE%'
     
    stage 'git push'
    //input 'git push OK?'
    bat 'git push git@github.com:srz-zumix/iutest.git develop'
    }
}

どうしたら良いかわからない
Pipeline script をいざ書こうと設定を開いたものの…
どう書けばいいのかサッパリわからない。。。

まず何をしたらいいのか分からない迷子状態です。
第7回大阪Jenkins勉強会の LT を思い返すと、スクリプトを Generate してました。

ということで、Pipeline Syntax を使ってみます。


① Sample Step から「bat: Windows Batch Script」を選んで出てくる ②「Batch Script」にバッチ処理をコピペで③「Generate Groovy」を押すと、スクリプトがに ④ に出てきます。


あれ？これで終わりじゃない？
でも、これじゃあ Pipeline になってないし、こんな感じにしたい！（し、まだ問題がある）

https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Stage+View+Plugin

ということで、次のステップ。
ステージを追加します。

ステージ
ここは詰まってないです。Pipeline Syntax で「stage」を選択して Generate すると
1
stage 'git push'
こんなスクリプトが出てくるので、コピーするだけ。簡単です。

問題はどうステージに分けるかですが、今回は以下のようにしました。
  1. コミットメッセージの作成
  2. git clone
  3. svn export
  4. git commit
  5. git push

ビルドパラメータを参照する
ビルドパラメータの参照ですが、今までのバッチ処理では環境変数として参照できていたので、Pipeline のバッチ処理でも環境変数で参照できると思ったのですが、そうでもないようです。

1
2
3
4
node {
    stage 'env'
    bat 'echo %TEXT_PARAM%'
}

このように「ECHO は <ON> です。」と出力されます。


では、どうしたらよいか。
Getting Started with Pipeline
こちらによれば、ビルドパラメーターは Groovy の変数としては見えるようです。

というわけで、以下のように環境変数に set して対応しました。

1
2
3
4
5
node {
    stage 'env'
    env.TEXT_PARAM=TEXT_PARAM
    bat 'echo %TEXT_PARAM%'
}

これでビルドパラメーターがバッチ処理から見えるようになりました。

input
動作確認ができるまで、最後の git push ステージに input を入れて push されないようにして検証してました。
これなんですが、第7回大阪Jenkins勉強会のときに川口さんがもっといい方法があるよ～的なことを言っていた気がしたのですが、忘れてしまいました。。。
なんだっけなぁ

最後に
最後に出来上がったパイプラインの実行結果です。


さらに、せっかくなので blueocean で表示。

blueocean についてはこっちを参照してください。
ブログズミ: [Jenkins] Blue Ocean を試してみる


さて、これで Pipeline がどんなものか分かりました。
これからは積極的に使っていこうと思います。
では。


投稿者 時刻: 0 件のコメント:
ラベル:

2016年8月2日火曜日

[C++] Shippable + Wandbox でテストしてテスト結果の集計までを行う

ブログズミ: Shippable + Wandbox で C++ の CI 環境構築
以前、上記記事で Shippable + Wandbox で C++ のテスト実行をするようにしたのですが、iutest v1.15.2(v1.15.1) で Wandbox でのテスト結果を xml 出力できるように対応したので、テスト結果の集計まで行うようにしました。

iutest + Wandbox
iutest の Wandbox 実行ツールを利用することで、iutest で記述されたテストコードを Wandbox 上で実行できます。iutest v1.15.2(v1.51.1) では、このツールに xml 出力機能が追加されました。
iuwandbox.py test.cpp --xml test_result.xml
--xml コマンドラインオプションを付けると、指定のパスにテスト結果の xml を出力します。

Shippable でテスト結果 xml の集計
Shippable では junit 形式のテストレポートが集計できます。
Shippable Build Configuration - Shippable Documentation

方法としては簡単です。
shippable/testresults フォルダを作成して、そのフォルダに xml ファイルをコピーするだけです。

e.g.
1
2
3
4
build:
  ci:
    - mkdir -p shippable/testresults
    - nosetests python/sample.py --with-xunit --xunit-file=shippable/testresults/nosetests.xml
詳しくはドキュメントを確認してください。
iutest の場合
iutest では以下のようにテストをしています。
（Shippable だけでなく Wercker + Wandbox でも同様の方法でテストを実行しています。）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
language: python
 
python: 2.7
cache: true
parallelized_test: true
 
branches:
  except:
    - gh-pages
 
install:
  - pip install requests
 
before_script:
  - export PYTHONDONTWRITEBYTECODE=1
  - make -C tools/fused
  - mkdir -p shippable/testresults
 
script:
  - cd tools/wandbox
  - python ./iuwandbox.py --list_options ${WANDBOX_COMPILER}
  - python ./iuwandbox.py ../../test/syntax_tests.cpp -c ${WANDBOX_COMPILER} -f"-DIUTEST_USE_MAIN=1" --default --boost nothing --encoding utf-8-sig --expand_include --verbose --xml ../../shippable/testresults/test_result.xml
 
env:
  matrix:
    - WANDBOX_COMPILER=gcc-head
    - WANDBOX_COMPILER=gcc-6.1.0
    - WANDBOX_COMPILER=gcc-5.3.0
    - WANDBOX_COMPILER=gcc-5.2.0 # travis (5.2.1)
#    - WANDBOX_COMPILER=gcc-5.1.0 # wercker
#    - WANDBOX_COMPILER=gcc-4.9.2 # circle ci
#    - WANDBOX_COMPILER=gcc-4.9.1 # wercker
#    - WANDBOX_COMPILER=gcc-4.9.0 # wercker
#    - WANDBOX_COMPILER=gcc-4.8.2 # wercker
    - WANDBOX_COMPILER=gcc-4.8.1
    - WANDBOX_COMPILER=gcc-4.7.3
#    - WANDBOX_COMPILER=gcc-4.6.4 # drone
    - WANDBOX_COMPILER=gcc-4.5.4
#    - WANDBOX_COMPILER=gcc-4.4.7 # snap ci
    - WANDBOX_COMPILER=gcc-4.3.6
    - WANDBOX_COMPILER=clang-head
#    - WANDBOX_COMPILER=clang-3.8 # travis ci
#    - WANDBOX_COMPILER=clang-3.7 # circle ci / wercker
#    - WANDBOX_COMPILER=clang-3.6 # semaphore
#    - WANDBOX_COMPILER=clang-3.5 # c++config.h not found
    - WANDBOX_COMPILER=clang-3.4
#    - WANDBOX_COMPILER=clang-3.3 # wercker
#    - WANDBOX_COMPILER=clang-3.2 # wercker
#    - WANDBOX_COMPILER=clang-3.1 # wercker
    - WANDBOX_COMPILER=clang-3.0
 
after_success:
  - echo OK
   
notifications:
  email:
    on_success: change
    on_failure: always



最後に
Wandbox でのテスト結果を xml ファイルに出力できるようになったことで、テストツールとして完成されてきた感じがしてきました。
iutest のテストとしてはかなり便利に使わせていただいています。
もう個人的には最強の環境になったかなと思います。

ただ、複数ファイルのコンパイルができない（ヘッダーは可能）ので、まだちょっとプロダクトのテストをするとまでは至っていませんが、ヘッダーオンリーなライブラリーとかであれば、かなり良いテスト環境になるのではないでしょうか。
投稿者 時刻: 0 件のコメント:
ラベル: , , , , , ,
登録: 投稿 (Atom)