Integromat で役目を終えたシナリオを自動的に停止させる

Integromat はシナリオでエラーが起こると、実行をしばらくポーズします。
ポーズしている間に、エラーを直しましょう。ということだと思いますが、
エラーのままにしておいて、一定回数ポーズをするとシナリオは Disable にされます。


（だんだんとポーズ時間が延びていき、6回目でシナリオが無効になりました。）

今回はこの挙動を利用して、役目を果たしたシナリオが自動的に Disable になるようにしてみました。

やり方

まず、役目を果たしたことをシナリオが認知しなければいけません。
その点はシナリオによって変わってくるので、ここでは説明しません。
今回は、すでに役目を果たしたことをシナリオで検出できており、そのノードが出来上がっている前提とします。

以下が、そのシナリオです。
Slack 通知が２つあると思いますが上が正常ノード。下は期間終了後のノードで、赤い丸をつけたところが、今回のポイントです。


この HTTP GET オペレーションは、存在しない適当なアドレスに GET リクエストをします。
このオペレーションは失敗します。が、これで OK です。


簡単にいうと、わざと失敗させています。
失敗すればなんでもいいので、正常ケースのオペレーションが、役目を果たしたあとの場合に異常ケースで失敗してしまう、でも（今回の目的では）問題ないです。

なぜこんなことが必要なのか

Free プランで使っているのですが、ちょっとリッチなシナリオを書いたり、一日に何回もトリガーする cron 設定にしたりすると、すぐに 1,000 operations 消費してしまってシナリオ実行ができなくなってしまって困ってました。
Operation の数を削減することもできるのですが、30分毎にトリガーすると 2 x 24 x 30 = 1440 で、仮に 1 operation でも全然足りません。

ただ、今回の場合、30分毎にトリガーする必要はあるものの、1ヶ月間ずっと必要ではなく1週間程度で良かったので、必要なときだけシナリオを有効にすれば OK でした。


・
・
・


自動化したいじゃないですが！

というわけで今回は、「自動で無効にする」ができました。
次は、「自動で有効にする」ができたら報告したいと思います。
（有効化は設定を書き換える必要があったりするので少し手間取りそうですが・・・）

では。

Wandbox の対応言語・コンパイラバージョンの追加を通知するアカウントを作った

こんにちは。
Wandbox の更新を通知する仕組みは前々あって、新しいコンパイラーが追加されるとリプライをくれるようにしてました。
ブログズミ: Wandbox のコンパイラー追加を通知する環境を作った

@srz_zumix [NEW!] C: gcc-8.2.0-c, C++: gcc-8.2.0
[Deleted] F#: fsharp-head

[Wandbox]三へ( へ՞ਊ ՞)へ ﾊｯﾊｯ https://t.co/9GNf3KoflL

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

それがいつからかリプライを送らなくなってしまってました。

srz_zumix [Deleted] F#: fsharp-head

[Wandbox]三へ( へ՞ਊ ՞)へ ﾊｯﾊｯ https://t.co/9GNf3KoflL

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

どうやら、Zapier 側で @ 付きのメッセージが制限され、@ を取り除かれてツイートするようになったためでした。


Zapier から Integromat への引っ越しも考えましたが、 引越し先でも @ 制限がかかる可能性は高いので、
Zapier はそのままに通知専用の Twitter アカウントを作成しました。

Wandbox News:
[NEW!] C: clang-7.0.0-c, C++: clang-7.0.0

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

— Wandbox-News (@Wandbox_News) 2018年9月21日

というわけで、@Wandbox_News をよろしくお願いします。

依存ライブラリの 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 があるたびにトリガーするのではなく、定期的に（１日１回とか）更新があったかどうかがわかればいいので、定期ビルド実行したときの Google Test の HEAD の commit hash を自分のリポジトリに保存する方法を取りました。
更新があれば diff が出るので、これをトリガーにしています。
これを行っているのが、brfore_script の部分になります。

更新を push して他サービスをトリガーする

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

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

定期ビルド設定

最後にこれを定期ビルドするようにしましょう。
こちらは 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 互換性テストを外部に出す対応に利用しようと思います。
では。

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 よりもプログラマブルに構築できるのがすごくいいです。

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

Dockerhub Automated Build が終わったら Slack に通知する

Dockerhub から slack 通知の方法は先人の方々が紹介されています。
これらの方法を採用しても良かったのですが、今回は自分なりに一番簡単な方法で通知するようにしたので、紹介したいと思います。

Zapier を使う

Zapier を使います。
以上！







いやいや紹介してませんがな(｀･ω･´)ゞ

Zapier とは？という方は、以前使った時の記事があるので、そちらを参照していただければと思います。
「ブログズミ: CIサービスの結果を Twitter に投稿する」
簡単にいうと IFTTT みたいなやつです。

設定

レシピは簡単です。
Webhook をトリガーに Slack の send message をアクションに設定します。


メッセージはこんな感じにしました。

New image was pushed to {{38337844__repository__repo_name}}:{{38337844__push_data__tag}}
{{38337844__repository__repo_url}}

最後に、Dockerhub の webhook に Zapier で作成した URL を設定します。


こんな感じに通知が来ますー

今回は以上です。

Google Home を買った

東京に来てだいぶ落ち着いてきたので、Google Home を買いました！

開封の儀 pic.twitter.com/fh4se2ldAo

— ずみっくす★ (@srz_zumix) 2017年12月3日

「すみません、お役に立てそうにありません」
そんなことばかり言わせてしまってますが、まぁまぁそれは今後に期待するとして…


やっぱり外部連携させたいですよね！
ということで、さっくりやってみました～

とりあえず IFTTT で連携

とりあえず IFTTT で連携できることはしっていたので、それを使うことにしました。

参考：
・Google HomeをIFTTTと組み合わせてTwitterやLineなどと連携しよう！ | ゆきの野望
・Google HomeとNatureRemoをIFTTTに連携してみる - Qiita

やり方とかは参考ページを見ていただければと思います。（二番煎じ、三番煎じなので）

「twitterで $ とつぶやいて」で $ の部分がツイートされるようにしてみました。
実際にやって結果がこちら。

おやすみ : Google Home

— ずみっくす★ (@srz_zumix) 2017年12月3日

入力判定のコツ

入力の判定にあたって、少しだけコツがありました。
入力は全部ひらがなで入ってくるわけではなく、アルファベットや漢字に変換されることです。
たとえば、「きょうはいつかえるの」をトリガーにしたい場合は、「今日はいつかえるの」では一致せず「今日はいつ帰るの」で一致しました。「ついったー」は「twitter」でした。
IFTTT では、キーワードは１つではなく複数設定できるので、いくつかバリエーションを登録しておくとイイかもしてません。

Google Home がどう認識したか確認する

Google Home がどう認識したか、ちゃんと確認できます。
セットアップで「Google Home アプリ」をインストールしたと思いますが、そちらのメニューの「マイ アクティビティ」を開いてください。
こちらがコマンドを認識させるのに役に立つと思います。

最後に

Google Home を使って色々やってみようと思うので、またここで報告できたらと思います。
では～

---

※今セールで半額なので買うには良いタイミングだと思います。

【楽天スーパーSALE限定価格】Google Home Mini チャコール 価格：3240円（税込、送料無料) (2017/12/5時点)

【楽天スーパーSALE限定価格】Google Home Mini チョーク 価格：3240円（税込、送料無料) (2017/12/5時点)

ビックカメラなら Mini じゃない Google Home も半額です！

ビックカメラ.com | Google Google Home GA3A00538A16

Wandbox のコンパイラー追加を通知する環境を作った

Wandbox で対応コンパイラーが増えたら、自分宛てにツイートしてくれる環境を作りました。

@srz_zumix [NEW!] C: gcc-7.1.0-c, C++: gcc-7.1.0, C++: zapcc-1.0.1 [Wandbox]三へ( へ՞ਊ ՞)へ ﾊｯﾊｯ https://t.co/9GNf3KoflL

— ずみっくす (@srz_zumix) 2017年5月30日

構成

Appveyor + Zapier

概要

https://github.com/srz-zumix/wandbox-news
ソースコードをみていただければ、どんなことやっているかはわかると思います。
特に難しいことはしてなくて、Wandbox API で取ってきたリストを成果物として保存して、前回との差分があれば Webhook を投げます。
あとは、Zapier で Webhook を受け取ってツイートするだけです。

その他

最初は、Google App Engine とか Circle CI とか使おうと思ってましたが、定期ビルド、Webhook Notification、成果物の保存・取得ができる Appveyor に落ち着きました。

あとは、Notification でカスタム json を作るのに、ちょっと手間取りました。
デフォルトで送ると Zapier で message を取るのがめんどくさかった（というか、うまくできない？）ので、カスタムで送るようにしてます。
url が secure 指定できなかったので、Web UI 設定にしてますが、appveyor.yml にコメントで書いてあるので参考にしてください。

では。


※更新なしが FAIL 更新ありが PASS になっているが、どちらも PASS にできるならしたい。
※Webhook を発行するトリガーとして、ステータスを利用しているため。
※最初は逆だったが、成果物取得で落ちてくるのが lastSuccessBuild のものだったため、更新があったときを PASS にしている。

※Zapier で tweet する際に改行がスペースに置換されてしまっている。
※改行のまま tweet したい。

Zapier + RSS で Twitter のツイートの音声読み上げをやってみたけど微妙だった話

Slack、読み上げてくれんかな。ラジオ感覚で聞きたい。 #開きに行って観るほどではないが把握くらいはしておきたい

— 三浦一仁(本読めるようになりたい) (@kazuhito_m) 2017年1月16日

わかる

— ずみっくす (@srz_zumix) 2017年1月16日

ということで、Slack ではないですが Twitter のツイート読み上げをやってみました。
（Slack でも outgoing webhook があるので Zapier で繋げられるはず）

が、結論を先に書くと
求めていたものとは違うものでした。

Twitter → RSS → 音声読み上げ

なぜこの構成にしようと思ったのか？
音声読み上げは PC 上でやっても良かったのですが、スマホで読み上げてくれたら XFD 的な感じで通知にも使えるしいいかなぁと思ったからです。
（あと、PC は作業用BGMとかかけてたりするとフロア全体には流せないですしね）

Zapier の設定

Zapier はサービスとサービスをつなげるハブサービスです。
以前書いた「ブログズミ: CIサービスの結果を Twitter に投稿する」に細かいことは書いてあるのでそちらも参考にしてください。

今回は Twitter → RSS の設定です。


まだトライアル版の期間内でしたので、フィルターも設定してみました。


ちなみに、無料プランだと 2 step までしかできないです。（うーん、ずるいなぁ。フィルター絶対欲しくなるもん…）


これで設定は完了。

RSS Reader で読ませてみる

今回使ったアプリは WalkReader です。
こんな感じに読み上げてくれます。（ブログでは声出ませんけど…）

結果

本当に欲しかったのは、とあるトリガー（今回は Twitter のつぶやき）に対して
「（ある程度）リアルタイムに反応して、自動でその内容を喋ってくれるもの」でした。
で、出来上がったのは
「5分～15分の更新頻度で、手動でその内容を喋ってくれるもの」でした。
全然ダメでした…
（まぁ、サービス連携を覚えたので色々やってみたかったんです。ダメでしたけど…）


まず、RSS Reader 側は自動で読み上げてくれるようなものを作ったり、既にそのようなものがあったりすると思います。
なので、解決できなくもないのですが、
Zaiper の更新頻度が有料プランでも "5分" であること、今回選択した RSS では受け側も常にポーリングしている必要があることなど、ちょっと下調べ不足でした。

つづく・・・

読み上げは個人的にやってきたいことの１つでもあるので、今後もいろいろ試していこうと思います。

では。