ラベル Travis CI の投稿を表示しています。 すべての投稿を表示
ラベル Travis CI の投稿を表示しています。 すべての投稿を表示

2020年11月10日火曜日

Travis CI の新プランについて

 The Travis CI Blog: The new pricing model for travis-ci.com

Travis CI の新しい料金プランが 2020/11/02 より始まり、あっという間にクレジットを使い切りました。


新しいプランでは 10,000 クレジットが毎月与えられ、それを消費するスタイルですが、圧倒的に足りない・・

こちら↑はブログからの抜粋ですが、マイニングとかに悪用されたのが理由のようです。
制限かかっても仕方がないな…とは思います。
が、今まで CI サービスの中でも制限ゆるい方だったのが、一気にキツめの部類になったので辛いですねぇ…
まぁ、今まで無料だからと気にせずマトリックス組んでましたが、このままではキツイので体制を見直すことにしました。(自作 C++ テスティングフレームワークの iutest で主に使ってて、複数パターンでテストしてました↑)
ただ、それでも 10,000 クレジットはあっという間になくなってしまうと予測されるので、サポートに OSS クレジットを申請してみました。

結果が来たら追記したいと思います。

Travis CI のかわりにオススメの CI サービスは?
さて、これを機に Travis CI から引っ越しする方も多いと思います。
GitHub Actions に移る方が多そうですが、別のサービスもオススメしておきます。

  • CircleCI
    まぁこれは知ってる人も使ってる人も多いと思うので、こっちに移る人も多いかも。
    OSS プランであれば 400,000 クレジット使えます。
    iutest の 2020/10 月の利用結果はこちら。まだ余裕あり
  • Drone.io
    Drone (Cloud)は OSS であれば完全フリーで使えます。
    並列数とか制限ありません(ただし、リソースは限られてる)
    iutest では gcc/clang の各バージョンでのテストをしています。
  • Azure Pipelines
    GitHub Actions よりは少ない 10 並列ですが、それでも強力な CI サービスです。
    GitHub Actions は(まだ)YAML のアンカー・エイリアスに対応していないので、独自のテンプレート構文が使える Azure Pipelines のほうが、マトリックスは組みやすいと思います。
    Travis CI でマトリックス組んでた人にはオススメです。
  • その他
    iutest では他にもたくさんの CI サービスを利用しているのでよければ参考にしてください。
最後に
DockerHub の pull rate limit の対応をしてたんですが、これまたインパクトのデカイ変更でした。。。このような CI サービスの悪用は他のサービスでも起こりそうな気がしてますが。。。今後の CI as a Service はどうなっていくんでしょうね。。。

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 上でデバッグできるようにしておくのは便利でいいですね。

今回は以上です。
では。

2019年11月27日水曜日

[Coverity][TravisCI] 設定の備忘録

TravisCI で Coverity Scan を使っているのですが、他のリポジトリでも使おうと思ったときに設定どうだっけ?と調べ直したので備忘録として残しておく。


さいしょに
Coverity Scan 側でプロジェクト作成したりとかは省きます。
そして、セットアップ方法も公式のドキュメントがあるので、そちらを見れば ok
https://scan.coverity.com/travis_ci

ただ、travis コマンドの使い方どうだっけなーとなるのでそこだけメモします。

COVERITY_SCAN_TOKEN を .travis.yml の env にセットする
トークンをセットします。そのまんま書いても動きますが、そんなことをしてはいけません。
セキュア変数にします。

travis コマンドのインストール
https://github.com/travis-ci/travis.rb#installation
こちらの手順に従ってインストールしましょう

トークンの設定
https://docs.travis-ci.com/user/environment-variables/#defining-encrypted-variables-in-travisyml
セキュア変数の作り方はこちらを参考にしてください。

travis encrypt COVERITY_SCAN_TOKEN= --add env.global

これで env global に COVERITY_SCAN_TOKEN 環境変数が追加されます。

今回は以上です。
では。

2019年8月28日水曜日

[Travis CI] Addons apt のリトライ設定

travis-ciにtravis_retryという失敗しても何度かリトライする機能があるらしい件 - xuwei-k's blog
Common Build Problems - Travis CI

Travis CI には 'travis_retry' コマンドが用意されているので、script でのリトライ対応はできるのですが、Addon の場合でもできないのか調べました。




答え:できる
For a more resilient apt operations, add retries by BanzaiMan · Pull Request #1343 · travis-ci/travis-build

addons:
  apt:
    sources:
      - ubuntu-toolchain-r-test
      - llvm-toolchain-xenial-8
      - llvm-toolchain-xenial
    packages:
      - clang-8
      - g++-9
      - gcc-9
    config:
      retries: true
https://github.com/srz-zumix/iutest/pull/279

2019年5月27日月曜日

[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

では。

2018年11月8日木曜日

travis-ci.org から travis-ci.com に移行しました



Travis CI といえば travis-ci.org だったんですが、
GitHub Checks API を試してみようと思って調べていたら
(そのへんのことはこちら→「ブログズミ: GitHub Checks 対応 CI サービスを使ってみた」)
travis-ci.com のことを知りました。

.com の方は今までは public リポジトリ(OSS)が対応していなかったようですが、public リポジトリも .com を利用可能になりました。
そして、GitHub Checks API に対応しているのは .com の方なので、移行が必要でした。

すでに .org の方でビルドされているプロジェクトは、すぐには .com は使えなくマイグレーションが必要です。(新規の場合は .com で登録できる)
ただ、マイグレーションに関しては順次行われるようですが、遅延しているらしく、すぐに .com に移行したい場合はサポートにメールで依頼する必要があります。
iutest で Checks API を使いたかったので、メール依頼を出してみました。





マイグレーションにあたっての注意点
上記キャプチャにも書かれていますが、マイグレーションをすると .org の方の履歴は消えます。 Web config 部分も消えます。
マイグレーション依頼のメールを出すと、最初に本当にいいのかと?注意事項の確認がされます。

Migrating repos from travis.ci.org to travis-ci.com currently has the following caveats:

a) the build number will be reset to zero
b) the repo on travis-ci.com will start with a blank build history
c) the old build history will still be available on travis-ci.org
d) environment variables will not be migrated
e) environment variables will need to be recreated and, where necessary, re-encrypted by the customer for use in .travis.yml
f) repo settings such as enabled push or pull builds, auto-cancellation etc will not be migrated

iutest の場合、履歴に関しては、別に消えても特に問題がないので OK
Web config 系は cron 設定くらいなので、とりあえず .org の設定をキャプチャしておきました。



最初のビルドは4年以上前だったみたいですね。ほー

Hello Travis-CI ".COM"!
メールで注意事項に対して問題ないことを伝えると、ほどなく移行完了メールが来ると思います。
あとは、退避しておいた Web Config を戻すのと、 Encrypting environment variables を使っている場合は再生成が必要になります。
(再生成の際には、 travis login --pro で .com の方にログインして行います。エラーメッセージが出ると思うのでやってみればわかると思います)

これにて、無事に移行が完了しました。

GitHub Checks
さて、最後に一番の目的である GitHub Checks を見てみましょう。

https://github.com/srz-zumix/iutest/pull/118/checks


ちゃんと出てますね!
各 CI の結果が GitHub のページに集約されるのは、いろんなサービスを使っている自分としてはとても助かります。
対応サービスが今後も増えるといいですね。

今回は以上です。

2018年11月1日木曜日

GitHub Checks 対応 CI サービスを使ってみた

さて、お気づきの方もいらっしゃると思いますが、GitHub の PR ベージに「Checks」タブが現れました。


こちらは、最近5月頃リリースされた Checks API 用のタブのようです。
Introducing the Checks API, a better way to connect integrations and code | The GitHub Blog
サード・パーティCIツールとのより深い連携を実現する新機能「Checks API」のパブリックベータ版を公開 | The GitHub Blog

CI での指摘がこちらのタブに集約される感じでしょうか。
これまでは、CI の「成功/失敗」はすぐに確認できたものの、失敗の内容は CI サービスに飛ばないとわからない(権限ないと見ることすらできない)状態だったので、これは便利になりそうです。


実際に使ってみた(失敗 PRの例)
iutest ではいろんな CI サービスを使ってますが、その中の1つ Cirrus CI が Checks API に対応して、タブに表示されていたのでそちらを例として紹介します。

テストが失敗すると↑のように Checks タブから確認できます。
Cirrus CI では OS および -std オプションをパラメタライズドに4つのテストが実施されています。サービスのぶら下がって4つのプレートが出ていますね。
それぞれ、プレートをクリックすると結果が確認できる仕組みです。

Re-run,Re-run all があるので、環境エラーなどで失敗してた場合に PR した側でも再実行できるので、それはレビュイーとしては助かりそうです。

最後に
PR ベースの開発をあまりしていないので、まだ使ってみた機会は少ないのですが、失敗原因を1つの画面で確認できるのは便利そうな気がしました。
早く他のサービスも対応していくといいなーと思いました。

今回は以上です。





ちなみに… Travis CI の表示がありますが、iutest ではまだ結果を Checks タブで見ることはできません。
実のところ、Checks API が出た5月ころにはもうこの記事を書いていて、Travis CI で試した感想を書こうと思ってましたが、いろいろあって(略)このタイミングとなりました。

編集後記1
供養
インストール
Checks タブを開くと Marketplace へのリンクがあるので開いて、お好きなものをインストールだけです。




といっても、iutest で使っている CI サービスで、
Checks API に対応しているサービスは現在(2018/6)時点では Travis CI くらいなので、そちらをインストールしました。
(インストール手順は特につまるとこもないので省略)

ここで文章は途切れている・・・
Travis CI は Checks Api に対応しているのですがタブができるだけで特に何も表示されませんでした。

0・・・

The Travis CI Blog: Announcing support for the GitHub Checks API on travis-ci.com


OSS , will soon , ははあーんまだか・・・
(まだそうだったので、記事作成を中断・・・)

・・・3ヶ月後
おおー Cirrus CI が Checks API に対応したでぇ!

Travis CI はまだかー・・・
と思いつつ、Cirrus CI で記事の続きを書くことにしました。

編集後記2
Travis CI の状況を確認
記事の続きを書くにあたって、 Travis CI の状況をちゃんと把握しようということでドキュメントを確認しました。
https://docs.travis-ci.com/user/open-source-on-travis-ci-com/#existing-open-source-repositories-on-travis-ciorg

どうやら、移行は勝手にしてくれるみたいですが、遅れているようです。
もし、ビルド履歴や設定(環境変数を含む)が消えてもいいのであれば、リクエストメールを送ることですぐさま移行ができるみたいです。

iutest の場合、設定は特に消えても大丈夫(月一定期実行してるくらい)で、ビルド履歴も数年間歩んできた思い出くらいの意味しかないので、綺麗さっぱり移行することに決めました。
travis-ci.com への移行手順は別途記事を書いてますので、そのうち公開する予定です。

公開したらここに追記

2018年10月24日水曜日

Travis CI に Windows がやってきた

The Travis CI Blog: Windows is Available (Early Release)
※1

Travis CI で Windows OS が使えるようになりました。
というわけで早速使ってみました。

ちょうど昨日、この記事に書いたことに対応した環境に更新されったっぽいので、状況変わってそうです。https://travis-ci.community/t/c-support-on-windows/282/10


iutest で試してみた
サクッと試したいので、既存のリポジトリを使って、Windows でのテストを追加したいと思います。
対象のリポジトリは iutest です。

概要
* https://github.com/srz-zumix/iutest
* C++
* CMake でビルド、テスト

差分
最初にできあがった .travis.yml の差分を見ていきましょう。
https://github.com/srz-zumix/iutest/pull/116/files
追加した変更が下記のあたりになります。



情報
Windows のビルド環境の情報は以下の公式ページにまとまっています。
https://docs.travis-ci.com/user/reference/windows

os: windows とすることで、Windows 上でのビルド・テストが実行できるようになるわけですが、
プリインストールされているツールやサポートされている言語など、こちらで確認しておくとよいでしょう。

基本的には公式ドキュメントを見れば、ジョブを組めると思いますが、 iutest で行ったことのうちポイントになりそうところを紹介していきます。

C++ はまだ対応言語に含まれていない
C++ はまだ対応言語に含まれてません。
現在(2018/10)、対応している言語は以下の4つです。
* Node.js (language: node_js)
* Rust (language: rust)
* Go (language: go)
* Bash variants (language: shell, language: sh)
https://docs.travis-ci.com/user/reference/windows#supported-languages

フォーラムに topic も上がってるので対応されるのを期待して待つとして、
Visual Studio がインストールされているので C++ のビルドができるでしょという期待のもと、 language: sh で一時しのぎしました。

pre-installed ツールにパスが通っていない?
Windows 環境のプリインストールツールは以下のようですが、cmake がいない(見えていない?)状態でした。
https://docs.travis-ci.com/user/reference/windows#pre-installed-packages

昔の記憶をたよりに、探してみると…
(Chocholatey をむかーし使ったときの記憶だと、インストールパスがツールによって異なったりして困ったことがあったので)
Program Files にいました!


というわけで、CMake 使う場合は下記のようにパスを通しましょう(今後の更新でデフォで見えてるようになることを願う)
export PATH=$PATH:${PROGRAMFILES}/CMake/bin
(ProgramFiles だった気がするんだが、PROGRAMFILES だった…??)

pre-install ツールが見えなかったら、デフォルトインストールパスを探してみましょう。

cmake --build でタイムアウト
cmake へのパスが通って、コマンドが無事叩けましたが、今度は cmake --build でタイムアウトしてしまいました。


AppVeyor ではどうしていたかな?と確認すると、そちらでは cmake --build を使わずソリューションファイル指定をして、msbuild が叩かれていたので、同じように msbuild を使うように修正しました。

MSBuild もパスが通ってない
(デフォルトで通ってて欲しいなー)こちらもパスを通しましょう。
Windows ビルドを調べていたら、find で検索してパスをセットしている .travis.yml があったので、そちらの方法に切り替えました。
(これで環境変わってもある程度大丈夫になるはず)
https://github.com/chensoft/libfs/blob/339aa134aa94a34b5c5a27f5a30a4d37a6af66d5/.travis.yml

CMAKE=`dirname "$(find '/c/Program Files'* -name 'cmake.exe' 2>/dev/null | head -n1)"`
      MSBUILD=`dirname "$(find '/c/Program Files'* -name 'MSBuild.exe' 2>/dev/null | grep 'amd64' | head -n1)"`
      export PATH=$PATH:"$CMAKE":"$MSBUILD"

MSBuild もタイムアウト
MSBuild に切り替えましたが、症状変わらずタイムアウト…
そこで Widonws ビルドに関係のない設定をすべて取り払って見たところ、ログが出ました。。。(うーん、謎)
https://travis-ci.org/srz-zumix/iutest/jobs/444078696
before_install:
  - |
    if [ "$TRAVIS_OS_NAME" == "windows" ]; then
      CMAKE=`dirname "$(find '/c/Program Files'* -name 'cmake.exe' 2>/dev/null | head -n1)"`
      MSBUILD=`dirname "$(find '/c/Program Files'* -name 'MSBuild.exe' 2>/dev/null | grep 'amd64' | head -n1)"`
      export PATH=$PATH:"$CMAKE":"$MSBUILD"
      echo $PATH
    fi
  - python .ci/travisci/travis_blocking_stdout.py || true

script:
  - |
    if [ "${USE_CMAKE}" == '1' ]; then
      set -e
      mkdir ./cmake-build && cd ./cmake-build
      cmake ../projects/cmake
      if [ "$TRAVIS_OS_NAME" == "windows" ]; then
        echo msbuild
        MSBuild.exe iutest.sln /verbosity:minimal
      else
        cmake --build .
      fi
      ctest -C Debug -V
      cd ..
    fi

matrix:
  include:
    - os: windows
      language: sh
      env: WINDOWS=1 USE_CMAKE=1
      before_script:
        - cmake.exe --version
        - cmd.exe /C echo test
        - MSBuild.exe --version
    - os: windows
      language: go
      env: WINDOWS=1 USE_CMAKE=1
      before_script:
        - powershell /?
    - os: windows
      language: rust
      env: WINDOWS=1 USE_CMAKE=1
    - os: windows
      language: node_js
      env: WINDOWS=1 USE_CMAKE=1
 

dist: trusty とか sudo: false が悪さをしているのかと思って試してみましたが、ログは出ず。
上記のような(マトリックスしてるのはテストのため)最小構成だと、ちゃんとログが出る。
(ちなみに、before_script で MSBuild.exe --version してるのもログが出ないので、ますますよくわからん)

tee コマンドで回避
結局は tee コマンドを介して上げるとログ出力がちゃんと認識されたので、それで回避しました。

なんとか完成
tee コマンドでなんとか問題回避できたので、ようやくビルド・テストに成功しました!


cmake --build でも tee すれば回避できました
というわけで、最終的に最初に示した YAML となりました。


最後に
ログ出力がなぜか出ず、タイムアウトしてしまうのに手こずりましたがなんとか Windows でのビルド・テストが Travis-CI 上でできるようになりました。
まだベータ状態なのでこれから改善されていくとは思いますが、この記事が誰かの参考になれば幸いです。。。


※1 マイクロソフトの許諾を得て使用しています。

2018年8月14日火曜日

依存ライブラリの GitHub を Travis CI で定期的に監視して DockerHub Automate Build を実行する(+ Codefresh ジョブを Trigger)

目的
開発中のソフトウェアがなんらかのソフトウェアに依存しており、その依存しているソフトウェアの最新の状態を常に追いたい。
具体的には、筆者が開発中の C++ テスティングフレームワーク iutest は、Google Test との互換性のために常に Google Test の最新の状態と互換性テストを行っています。

iutest では Travis CI や Circle CI といった CI サービスを利用して、変更があるたびにテストが行われる環境が整っています。
しかしながら、iutest は毎日更新があるわけではなく、最近は開発スピードも落ちているので数日変更がないこともザラです。
そのため、その間に Google Test に更新があって、いつの間にか互換性テストが通らない状態になっていたりすることがありました。

長くなりましたが、今回のゴールは
・ Google Test の更新を定期的に監視して
・ 変更があったら Docker image を更新
・ Docker image が更新されたら互換性テストが実行される
です。

構成

* 監視されるリポジトリ→ google test
* 監視するリポジトリ→docker-googletest


DockerHub Automate Build
DockerHub で Google Test の入ったイメージを作成するジョブは以下の記事で作成したものを使用します。
ブログズミ: DockerHub Automated Build を使ってみた

今回はこちらの latest イメージを毎日最新の状態にするのが目的です。
DockerHub に定期ビルド機能があればそれで良かったのですが、ないので別のサービスで実現させます。

次へ進みます。

CI の設定
必要なのは、定期ビルドが可能で、GitHub に push できるサービスです。
今回は Travis CI を使いましたが、選んだ理由は最近 GitHub push をここでやったからです。
実際使用している yml はこちらです。こちらを見ながら説明していきます。
dist: trusty
sudo: false
language: cpp

before_script:
  - git clone https://github.com/google/googletest.git ./gtest
  - cd ./gtest
  - git rev-parse HEAD > ../gtest.hash
  - cd ..

script:
  - git checkout master
  - git add -A
  - git commit -m "update head [ci skip]" || true
  - git push https://${GITHUB_TOKEN}@github.com/${TRAVIS_REPO_SLUG}.git ${TRAVIS_BRANCH}

env:
  global:
    secure: OdxIMgUsZyGyOOnV49MkJW5KrGVW7KyCwUkWgC88YmdJPCtNJ9fF69TcM8ek252+yFJsfpUrZaNH6A6igRUreveoA161zy+fsD9mMqIrrthFWx5S2fzBCsiCobreduicCDt5EJ1p8N/QlpEB2ZeUbYWqZf37r5BfYOJI86521qYMiI30IAwxsjPqhcbyFRisTKosd3LlEo4Y+K3qLgdCKEAhsaOrtIgrbxz7cM2sKh8lYTquP1XPtFwsmCoELyeRAVEJbSwADcaw3011S/NB8Kn9+sd878dxBK2iDxSilVz+3XIz+/sKZHNFGug5i2UA2yS8ZfWQhZjF9tiF3quTAzqAFzTbxDKswMLHgD8oI0saIVDmXNxc6PXLYXEjx5p5Z3E1iTb09hcp5wOqJOz+Ynie7EkVyUO2DKJhjeuGffoPxjK35L4c7/ufTNskT3+vUnGG/2U9XMA3OeXoCLp+V7BRgkZtpVZssA4viTWXPG4byaEQaiAMK0ArVOesa86m21xuKSLhdNqQ/WRT8g/eEVqs4XrT1ogIW1nsjYHv6Xmcs8QD2iQxDdWHx4pQojod8lSdwn/HFqXTOf6KxqTk5mpJmcd2ZxyDocynTEtvtt+uNtVyJh+gXt06eGD/rlbV1eC+Uc5FMQE2P1Uya3RdaZvMZjYGzVcZMrPcv/gklbY=

Google Test の更新検知
まずは肝心の Google Test (監視される側)の更新検知方法です。
いろいろやり方はあると思いますが、今回は push があるたびにトリガーするのではなく、定期的に(1日1回とか)更新があったかどうかがわかればいいので、定期ビルド実行したときの Google Test の HEAD の commit hash を自分のリポジトリに保存する方法を取りました。
更新があれば diff が出るので、これをトリガーにしています。
これを行っているのが、brfore_script の部分になります。

更新を push して他サービスをトリガーする
最新の commit hash を取得したら、それを commit/push します。
docker-googletest (監視する側)のリポジトリが更新されるので、この push をトリガーに他のサービスをキックすることができます。
監視する側のリポジトリは自身の管理下のはずなので、ここから先は自由にやることができます。

ただし、ここで注意点があります。
Travis CI のジョブもこの push をトリガーにより実行されてしまいます。
すると、この Google Test 監視ジョブが再実行されてしまい、最悪の場合は無限にジョブをキックし続けます。(監視される側の更新が止まれば止まるが、最低でも1回無駄にジョブが走る)

定期ビルド設定
最後にこれを定期ビルドするようにしましょう。
こちらは Travis CI の Web ページで設定します。
プロジェクトのページの「More options」から「Settings」を開くと、一番下に Cron Jobs があります。



DockerHub Automate Build の設定
特に必要ありません。
Google Test が更新されると、commit hash が更新されて push されるのでそれをトリガーにビルドが実行されます。

おまけ
ここまでで、当初の目的の GitHub の監視と、変更検知し DockerHub のビルドを回す、という目的は達成していますが、ついでなので、その先も紹介します。

Slack 通知
通知系は定番ですね。詳しくは過去にも記事にしているので、そちらを見てくださいmm
ブログズミ: Dockerhub Automated Build が終わったら Slack に通知する

docker-googletest の通知仲介は Zapier を使ってますが、今は Integromat もおすすめです。
そちらも記事にしているので、よければご覧ください。私的には、今後は IFTTT/Zapier よりも Integromat をメインに使っていくつもりです。

* 「ブログズミ: プレビュー "(WIP)依存ライブラリの GitHub を Travis CI で定期的に監視して DockerHub Automate Build を実行する(+ Codefresh ジョブを Trigger)"
* 「ブログズミ: CIサービスの結果を Twitter に投稿する

Codefresh のジョブを Dockerhub からの Webhook で実行する
Codefresh のトリガーに Webhook トリガーを追加します。
プロジェクトの「Pipeline」ページの真ん中あたりに「Triggers」があるので、そこで追加していきます。


「ADD TRIGGER」ボタンを押すと以下のようなウィンドウが出てくるので、「REGISTRY」を選択して次へ


続いて、「REGISTRY PROVIDER」を Dockerhub に、「NAMESPACE」と「NAME」はトリガーを発行したい Dockerhub のリポジトリを設定してください。
「ACTION」は Image 更新したときにしたいので、 「Push Image」を選択。docker-googletest にはバージョンごとのタグが複数あり、ビルド対象にしたいのは latest だけだったので、「Configure filter」を設定しました。
入力完了したら、「NEXT」ボタンを押します。


四角く囲ったところに、Webhook の URL と鍵が発行されますので、Dockerhub の Webhook に設定します。(下線のリンクから飛べます)


Dockerhub の Webhook 設定を開いたら、${ENDPOINT}&secret=${SECRET KEY} を入力します。(↑の黄色で囲った部分に出てるアドレスです)



これで完成です。


最後に
外部の依存・関係しているプロジェクトが、いつの間にか更新されていて動かなくなっていた。なんてことはよくあることなので、定期的に監視しておくのはいいことだなと思いました。
あと、この仕組がわりといい感じに組めた気がするので、iutest の Google Test 互換性テストを外部に出す対応に利用しようと思います。
では。

2018年7月31日火曜日

Travis CI の結果をツイートするのを Zapier から Integromat に引っ越した

Integromat とは


IFTTT のようなサービス連携サービスです。
IFTTT よりもプログラマブルで、Zapier よりも無料で使える機能が多い感じです。

なぜ引っ越したのか?
目的: プルリクかどうかがわかる通知をしたい

今までの通知はプルリクだった場合に、マージ先ブランチを報告していたため、あれ?と思うことがありました。
(↑は master のビルド結果を報告していますが、PR を master にマージした状態でテストされています)

IFTTT はシンプルにサービス連携ができて便利なサービスですが、条件分岐などが難しいです。
Zapier はアクションを複数付けられ、条件フィルターもできますが、無料プランだと制限されていたりして、少し不便でした。
Integromat はこれらの問題が解決できるサービスだったので引っ越しした理由です。

できたもの


Webhook → JSON Parse → 分岐 → プルリクかどうかのフィルター → Tweet って感じです。
Pull Request のビルド結果ツイートはこうなりました。



おー PR URL がプレビューされていい感じだ

シナリオを作成手順
まずは、必要なモジュールを選択します。今回必要なのは、Webhook と Twitter なので2つを選択します。
(ここで全部選択しなくても、あとでいくらでも追加できます)


次に進むと編集画面が開きます。まずはトリガーから設定していきましょう。


「?」マークのモジュールを選択すると、モジュールの選択画面が出てきます。
今回は、Travis CI の Webhook をトリガーにするので、Webhook を選択します。


TRIGGERS から 「Custom webhook」を選択します。


Webhook の設定
詳細は公式ドキュメントを → Webhooks | Integromat

どの Webhook を使うとリストから選択しますが、最初は Webhook は空なので作成します。
「Add」ボタンを押しましょう。


Webhook の名前を付けます。なんでもいいので、今回は「TravisCI」としました。
(アドレスを知っていれば誰でも叩けてしまうので、もしそのようなことを避けたいのであれば IP 制限がで対応できるようです)


Webhook を作成したら、作成した設定をリストから選択しましょう。
Webhook URL がその下に表示されるので、コピーして呼び出し元にセットします。
今回の場合は Travis CI の notification に設定しました。詳細は略。
ブログズミ: CIサービスの結果を Twitter に投稿する
こちらの記事に少し書いてます。


JSON parser の設定
続いて、 Travis CI の Webhook についてくる json を扱えるようにパーサーを通します。
Webhook からモジュールを生やして、 JSON から、「Parse JSON」を選択します。
Webhook のときと同様に、最初は設定がありませんので、設定を追加します。「Add」ボタンを押しましょう。



まずは、名前を付けましょう。ここはわかりやすい名前であればなんでも大丈夫です。
続いて、JSON の構造を定義していきます。1つ1つ定義を追加もできますが、めんどくさいので、Travis CI のサンプル json を食わして自動的に生成をしましょう。
「Generator」ボタンを押します。


「Sample data」に、Travis CI のサンプル json をコピペします。
raw text がコピーしやすいのでオススメ。
https://gist.githubusercontent.com/travisbot/4e317d6e71be6d0278be46bb751b2f78/raw/44327162583c4900aa9f9b51e2defacb3190ebfd/webhookpayload.json



設定を Save して、リストから生成した名前を選択したら JSON の設定は完了です。

Tweet の設定
Webhook で送られてくる内容を扱えるようになったので、先に Tweet の設定から説明します。
Webhook や JSON と同様にモジュールを追加し、Twitter から「Create a tweet」を選択します。


アカウント連携していない場合は、「Add」ボタンから設定します。(略)
ツイートの内容は、流れて来た JSON の内容が使えるようになっているので、お好みで設定してください。


ルーターと条件の設定
さて、最後に今回のキーポイントです。
プルリクだった場合のツイートと、そうでなかった場合のツイートの分岐を作っていきます。
このような分岐を作る場合は、TOOL にある「Router」モジュールを使用します。もしくは、モジュールとモジュールの間の設定マークから「Add router」をします。


「Router」を「Parse JSON」と「Create a tweet」の間に挿入し、「Router」からもう一本分岐して、「Create a tweet」モジュールを追加します。


モジュール間の連結にはフィルターを設定できるので、これを使って「条件分岐」にしていきます。
設定マークをクリックして、「Set up a filter」をクリックしましょう。


フィルターにはラベル名と、Condition の設定をします。
今回はプルリクかどうかを判断するため、Webhook payload に含まれている「pull_request」を条件にしました。
簡単ですね。


PR の yes/no でそれぞれフィルターを設定したら、条件分岐の完成です。


完成
これで完成です。


無料プランでは当然制限がありますが、よっぽどヘビーにトリガーしなければ問題ないですし、なにより IFTTT や Zapier よりもプログラマブルに構築できるのがすごくいいです。

是非みなさんも使ってみてください。では〜