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

Integromat とは

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

なぜ引っ越したのか？

目的： プルリクかどうかがわかる通知をしたい

今までの通知はプルリクだった場合に、マージ先ブランチを報告していたため、あれ？と思うことがありました。

@srz_zumix iutest master build 1569 is Still Failing https://t.co/dSr7nsZqv8

— Z.Z.ずみっくす (@srz_zumix) 2018年5月31日

(↑は master のビルド結果を報告していますが、PR を master にマージした状態でテストされています)

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

できたもの

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

@srz_zumix iutest develop build 1658 is Passed https://t.co/Y0cahzfBtN
PR: https://t.co/CWk1Kob8ew
feature c++17 #47

— Z.Z.ずみっくす (@srz_zumix) 2018年7月25日

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

シナリオを作成手順

まずは、必要なモジュールを選択します。今回必要なのは、Webhook と Twitter なので２つを選択します。
（ここで全部選択しなくても、あとでいくらでも追加できます）


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


「？」マークのモジュールを選択すると、モジュールの選択画面が出てきます。
今回は、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 の構造を定義していきます。１つ１つ定義を追加もできますが、めんどくさいので、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 よりもプログラマブルに構築できるのがすごくいいです。

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

osdn-cli でパッケージリリース

前置き

本当は CI サービスを使った自動パッケージリリースをやろうと思っていたのですが、最初に試した osdn-cli がローカルマシンで使う想定だったため、実現できませんでした。
CI サービスなどからリリースする場合は、ファイルリリース機能を使うのではなく、ファイルストレージ機能を使うといいみたいです。

あるプロジェクトからの要請でローカルなホーム上でのコマンドラインで使うことのみを想定したツールですので、ほぼ使えないかと思います。CIと連携する場合はファイルリリース機能ではなく、ファイルストレージ機能を使うほうが良いかと思います。

— Shuji Sado (@shujisado) 2018年6月29日

できあがったもの

なにはともあれ、osdn-cli を使ってパッケージリリースする方法は習得できたので、もったいないのでまとめました。

パッケージの作成

パッケージはすでに作成済みの前提です。
基本的にパッケージは一度作成したら変えることがないと思いますので、自動化から除外してます。

一応、
作成する場合は、 osdn package create で作成することができます。
既存かどうか判断しないと増え続けるので注意が必要です。
この辺はリリースの作成と同じような手順で対応できると思います。

リリースの作成

パッケージにリリースを作成します。以下のコマンドで作成しますが、まだファイルは一切アップロードしてない状態です。また、公開タイミングは手動で行うので、-v hidden オプションで非公開にしています。

osdn release create -v hidden --package $PACKAGE_ID $RELEASE_NAME

パッケージIDの取得

リリースを作成するときにパッケージの指定が必要になりますが、こちらは id 指定なので名前を指定してもダメです。
ID をベタ書きしてもいいのですが、汎用的に以下のコマンドで取得しました。

PACKAGE_ID=`osdn package | grep -o '[0-9]* iutest ' | cut -d ' ' -f 1`

パッケージのリストを出力、#ID 名前で出力されるので grep して ID を抽出してます。

リリースIDの取得

osdn release create では同名のリリースが既存であろうとなかろうと関係なくリリースを作成します。
そのため、すでに同名のリリースがあった場合は作成をスキップし、リリースIDの取得のみを行います。
リリースIDの取得は省略します。だいたいパッケージIDの取得と同じです。

最初に同名リリースを検索し、なければ osdn release create を行います。
その後リリースIDを取得しますが、これはファイルアップロードする際に利用するためです。

ファイルアップロード

osdn frs_upload --package $PACKAGE_ID --release $RELEASE_ID $FRS_RELEASE_ROOT

ファイルのアップロードは frs_upload を使いました。
パッケージとリリースIDを指定し、アップロードしたいディレクトリルートを渡したら OK です。
iutest のスクリプトでは、frs_mkdirs で各リリースのディレクトリを構築して、そこにリリースするファイルをコピーして、それをアップロードする形にしました。

アップロード後の作業

リリースノート・変更履歴の設定

上記リリーススクリプトで、リリースノートと変更履歴のファイルもアップロードするようにしています。
RELEASENOTE や CHANGELOG といった予め決められたファイル名のファイルを認識してくれる機能を利用しています。
ファイルリリースガイド - OSDN ヘルプ - OSDNドキュメント管理 - OSDN

ただ、このファイルをアップロードしてもそれだけではリリースノート・変更履歴として、表示されませんでした。これらのファイルを表示させるには、リリースの編集からチェックを変更して保存する必要がありました。


これ、ちょっと面倒ですね。。。


あ、あと、リリースノートとか変更履歴のファイルは非公開にすると、当然のようにリリースに表示されなくなります。
（別にファイルとしてダウンロードさせたいわけじゃないので、ファイルは非公開だけどリリースには表示されると嬉しかった）

ステータスを公開に変更する

リリース作成・ファイルアップロードを自動化しましたが、公開状態にするのは手動でやるように あえて したので、公開準備ができたらリリースページに移動して、ステータスを公開にします。



これで、リリース作業が完了しました。

最後に

デプロイを自動化、 CI サービスで動かして完全自動化といきたいとこでしたが、
それでも今まで手動で AppVeyor からパッケージダウンロードして、手動で OSDN のリリースを作成していたのを考えれば大分楽になりました。
引き続き、このスクリプトは利用しますが、ファイルストレージ機能を使ったデプロイになる早で移行したいなーと思います。

ではでは。

[CI] Buddy を始めました

久しぶりに新規 CI サービスを使ってみたエントリーです。
今回は Buddy です。

特徴

Buddy の特徴は Pipeline にあると思います。
他の CI サービスでもパイプラインで CI を構築できると思いますが、Buddy のパイプラインはアクションを選んでつなげるだけって感じでお手軽な印象を受けました。
また、（ここで紹介するということは）無料プランもあります。
（120ビルド/月なので他のサービスと同等かな）

SignUp

連携するアカウント（GitHub or Google or Bitbucket）を選択し、認証したらサインナップ完了です。

プロジェクトを作る

サインナップができたら、まずはプロジェクトを作っていきます。

GitHub や Bitbucket と連携している場合は、連携したサービスからリポジトリを選択します。
プロジェクトの作成はこれで以上です。



つづいて、パイプラインを作りましょう。

パイプラインを作る

まずは、パイプライン名とトリガーの設定、対象のブランチを決定します。


次にアクションを設定します。アクションは１つのパイプラインにつき、いくつも連結することができます。まずは、1つ目のアクションを作成しましょう。
アクションはプリセットが用意されていますので、まずはやりたいことから検索してみると良いです。
とりあえず自由にアクションをさせたい場合は、Local Shell などにするとよいでしょう。


選択したアクションにより設定内容が変わりますが、次に環境の設定をします。
今回は Local Shell を選択したので、実行環境の Docker コンテナイメージを設定します。


「Add this action」 ボタンを押すとアクションの作成が完了です。


以下のようにパイプラインにアクションが追加されていると思います。
あとは、アクションの前後にある「＋」ボタンから、アクションを追加していけばパイプラインが完成します。



作ったアクションは個別に ON/OFF できるのも便利だなーと思いました。

buddy.yml

Buddy は yaml にも対応しています。ドキュメントはこちら。
Yaml Introduction - Buddy

デフォルトは GUI でのコンフィグになっているので、yaml コンフィグに切り替える場合は、プロジェクトページの右下にある「YAML configuration」で設定を変更します。


注意： 設定変更のトグルがありますが、これを YAML に変更した瞬間、GUI のコンフィグは消し飛びます。まずは、切り替える前に出力された yaml テキストをローカルに保存しましょう。ファイル名は「buddy.yml」です。


buddy.yml を commit/push したら、改めて上記画面を開き、トグルスイッチを YAML に切り替えましょう。
これで変更完了です。

逆に YAML から GUI に戻す場合は、トグルスイッチを GUI に戻すだけで良さそうです。
（再び YAML に戻す場合は、設定が消えないように注意しましょう）

バッジ

Buddy ではパイプラインのステータスバッジと、ブランチのステータスバッジの2種類があります。
パイプラインのバッジはすぐに見つかると思いますが、パイプラインのページの右側に「Badge」リンクがあるので、そちらから参照できます。


ブランチのステータスバッジは、「Code」タブを開いたページにある「Badges」リンク取得できます。
こちらが他の CI サービスのバッジと同等のものになると思います。

最後に

Buddy はパイプラインを売りにしているだけあって、UI 上でパイプラインを構築するのはわかりやすく簡単でした。
また、Wercker と違って中途半端に yml 依存がなくて、ちゃんと Web 上の設定だけでパイプラインがちゃんと構築できるのも嬉しいところです。
パイプラインからパイプラインにつなぐこともできるので、比較的自由度もありそうです。

加えて、YAML コンフィグにそのまま切り替えもできるので、そこも Wercker よりいいなと思いました。
どうしても、 Wercker と比べてしまいがちですが、Wercker のほうは yaml に書いたビルドをパラメタライズする感じでパイプラインを構築できるので、そこは Wercker のいいところだと思ってます。
Buddy でも似たことができるのかもしれませんが、今回はここまでとします。

ではでは。

[CI][Review] Codacy を使ってみた

コードレビュータイプの CI サービス Codacy を使ってみました。
レビュー系のサービスは SideCI や Rocro 、Scrutinizer (これ覚えにくい) を使ってきました。
今のところ C++ のサポートがある Rocro が一番助かってるのですが、この Codacy でも C++ がサポートされているのは嬉しいですね。

では、早速使っていきましょう。

Sign Up

解析したい iutest は GitHub で管理してますので、GitHub で Sign Up します。


権限付与すると、登録完了です。
Welcome Back 画面が出てくるので、もう一度 GitHub アカウントでログインします。


すると、さらに権限を要求されるので許可します。


ダッシュボードが表示されます。これで Codacy が利用できる状態になりました。

解析してみる

では、早速コードの解析をしてみましょう。
先程のダッシュボードにリポジトリがリストアップされており、それぞれチェックボックスがついています。
解析したい対象のレポジトリにチェックを入れてみましょう。

すると、解析が始まりますのでしばらく待ちます。、


結構待ちます。
というか、Reviewing... から進みません。そのうちレビュー完了のメールが届きます。
メールを待ちましょう。

解析結果は以下のような形で確認できます。

iutest は他のサービスで静的解析をしているおかげもあって比較的クリーンな状態でした。

カスタマイズ

拡張子の関連付け

iutest では *.ipp という拡張子のファイルを使用しています。こちらは C++ で書かれたファイルなのですが、デフォルト設定では認識されてませんでしたので、拡張子設定をします。
設定場所は「Settings」の「File Extensions」にあります。

無視ファイルの設定

解析対象外のファイル・フォルダを指定できます。
docs とかはデフォルトで対象外になるようです。

リポジトリを階層表示してくれるのでわかりやすくていいですね。

ツールの設定

解析ツールの警告 On/Off の設定ももちろんできます。
こちらは Settings ではなく「Code Patternｓ」で設定します。

Badge

最後にお約束のバッジの付け方です。
「Settings」の「General」

まとめ

Codacy を使ってみましたが、簡単に始めることができ、すぐに静的解析の恩恵を受けられるのはとても便利だと思いました。
ただ、他のサービスでも同等のことはできているので、「Codacy だからこそ」という点は見つけられませんでした。

今後も使用していくので、ここはいいな！というところがあったら、紹介したいと思います。

では。