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 でした。


・
・
・


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

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

では。

[GitLab CI] マトリックスを組んでみた

GitLab CI でマトリックスを組んでみました。

Matrix Builds in CI - Questions & Answers / GitLab CI - GitLab Forum
方法は２つあって、YAML のアンカーを使った方法と、それと同等の extends を使った方法です。
（マトリックス分べた書きすればどんな CI サービスでも複数ジョブは実現できるが、重複する冗長な部分をまとめて簡潔に書けますよーという感じ）

Anchor を使った方法

YAML にはアンカーとエイリアス記法が存在します。
これは GitLab の YAML の機能ではなく、YAML の標準的な記法のため、別の CI サービスでも応用できると思います。

Anchors - Configuration of your jobs with .gitlab-ci.yml | GitLab
以下は公式の例を参照しています。

.job_template: &job_definition  # Hidden key that defines an anchor named 'job_definition'
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
  script:
    - test1 project

test2:
  << *job_definition           # Merge the contents of the 'job_definition' alias
  script:
    - test2 project

&名前 でアンカーを作成し、*名前でアンカーを参照します。
また、 「<< *名前」とすると、アンカーの内容をマージしてくれます。

つまり、共有部分をアンカーとして定義し、マトリックスジョブに可変部分を定義、あとは共有部分をマージすれば簡単にマトリックスを組むことができます。
（今回は後述の extends で書いたので実例は省略）

extends を使った方法

こちらは GitLab 11.3 で導入された GitLab の機能になります。
アンカーを書かずとも、extends で指定した YAML 要素を展開できる機能のようです。
アンカー記法やその参照方法を知らなくても、より直感的に書けるのでこちらをオススメします。

extends - Configuration of your jobs with .gitlab-ci.yml | GitLab
アンカーの例を extends で書き直すと以下のようになります。」

.job_template:
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  extends: .job_template
  script:
    - test1 project

test2:
  extends: .job_template
  script:
    - test2 project

（アンカー記法を見たあとだと、どっちでも良くない？となりますが、知らない人からしたら読みやすくなってるとは思います。）

iutest-test での実例

さて、最後に実例として iutest-test の例を紹介したいと思います。
iutest-test がどういったもので、どんな CI をしているかは以前に書いたこちらの記事を参考にしてください。
「ブログズミ: iutest のテストをするリポジトリ iutest-test を GitLab/GitLab CI に引っ越しました」

今回、マトリックスを組むことにした理由は、CI するブランチの対象を master のみから、master|develop に変更しようと思ったからです。
iutest-test でしているテストの重要度は高いわけではないので、１日１回 master ブランチを対象としていましたが、やっぱり master にマージしてからじゃないと状態がわからないのはよくないなと思い、develop でも１日１回実行すようにしました。


YAML はこちら→iutest-test / .gitlab-ci.yml


これで、定期ビルドでサブモジュールの更新が master / develop ２つに対して行われるようになりました。

最後に

今回のような定期ビルドの環境変数をマトリックスにしたいようなケースはパイプラインでなくても、トリガー固有の環境変数定義でもできると思います。
ただ、YAML のアンカーにしろ、extends にしろ、書き方を知っておくと、いざというときに役に立つのではないかと思います。

というわけで、早速アンカーを使った他の CI サービスの YAML を DRY にしようと思います。
今回は以上です。
では。

[Buddy] not enough disk space でエラーが出たのでキャッシュ削除をした話

Build failed: not enough disk space. The size of files generated by your build exceeds 5120 MB. Please run the execution with 'Clear cache' to free space in the filesystem or contact support@buddy.works to increase the size limit.
Action failed: see logs above for details

キャッシュクリアしたら回復しそうなので、方法を調べました。

マニュアル実行のオプション

調べるまでもなく、マニュアル実行するときのオプションがあるのを（たぶん） Buddy を使ってる人なら知っているでしょう。


しかし、これをやっても面白みがありませんし、できるならば手動実行ではなく、自動で勝手にいい感じにキャッシュクリアできたら一番です。
というわけで、検索してみました。
（Not Recommended ですし…）

コミットメッセージコマンドからクリアする

Buddy v1.5.1 Released - Buddy

だいぶ前のリリースノートですが、コミットメッセージに「--clear-cache」と入れると、キャッシュをクリアしてくれるようです。

How Use Commit Commands - Buddy
ドキュメントには一切書かれてませんが、試してみました。




結果は・・・


キャッシュクリアされてました！
でも、ビルドは失敗してる・・・

デフォルトでキャッシュクリアするように YAML に書く

iutest のパイプラインは as Code しているので、YAML で設定できないか調べてみました。
Yaml Schema - Buddy

auto_clear_cache Boolean Defines whether or not to automatically clear cache before running the pipeline .

YAML Schema を見てみると、auto_clear_cache を設定できるようだったので試してみました。




結果は・・・


キャッシュクリアされてました！
でも、ビルドは失敗してる・・・

結局マニュアル実行

なぜだ…という気持ちを投げ捨てて、結局マニュアル実行しました。。。





結果は・・・


成功した！？
なぜだ・・・

まとめ

ビルドの結果はともかく、
Buddy でキャッシュをクリアしてビルドする場合は、以下の３つの方法が取れます。

* コミットメッセージコマンド「--clear-cache」
* YAML の「auto_clear_cache: true」
* マニュアル実行時の「Clear cache before running」

もやっとしますが、今回は以上です。
では。