CircleCIのScheduling Jobの注意点など

対象

CircleCI 2.0

Schedulingとは

CircleCIでは、jobを定期的に実行するための仕組みとしてworkflowにscheduleという設定を行うことができる。
多くの場合はgit pushなどのイベントをトリガーとしてjobを実行すれば良いが、End-To-Endテストなど極端に時間がかかるjobや、脆弱性のチェックなどリポジトリ以外の要因によって結果が変わる場合があるjobについては定期的にjobを実行させた方が望ましい。
それを実現するための仕組みがSchedulingである。

なぜCircleCIのSchedulingを使うのか

定期的な処理を実行する仕組みとしては、cronやJenkinsなども挙げられる。
これらに対してCircleCIのSchedulingを使う利点として、CIという用語にも使われているContinuous(持続的)という点が挙げられる。
cronやJenkinsの問題点は、ジョブの設定がソースコードと分離されているというところにある(もちろんソースコード用に設定情報を配置することもできるが、設定情報を配置しただけでは動作しない)。このことにより、開発者がジョブの設定を認知していなかったり、ジョブが失敗しても気づきにくく、結果としてCIの持続性が失われてしまうリスクがある。
そのため、ソースコード上に設定を配置するだけで動くCIであるCircleCIのSchedulingを使うことが望ましい。なお、この点はTravisCIなど別のCIも同等である。

使い方

実行時間の設定方法はcronの設定と同様となる。以下に毎日20:00(デフォルトでUTC)にdaily-jobを実行する場合の設定を示す。

version: 2
jobs:
  daily-job:
    # 省略

workflows:
  daily-workflow:
      triggers:
        - schedule:
            cron: "0 20 * * *"
            filters:
              branches:
                only:
                  - master
      jobs:
        - daily-job

注意点1. 動作確認

上記のようなCircleCIの設定をPull Requestで追加する場合、動作確認において以下の問題点がある。

masterブランチで動作する設定にしていると、Pull Requestのブランチでは動かない
指定した時刻にならないと確認できない

これらを解決するには、対象のjobをAPIで実行して確認するか、一時的にブランチや時刻を変更したcommitをpushするといった方法を取らなければならない。

注意点2. 結果の通知

CircleCIには、Slackなどのチャットツールやメールにjobの結果を通知する機能があり、設定によりJobの失敗/復旧時のみ通知するように設定することができる。
しかし、この設定はJobやWorkflowを区別できないという問題がある。
例えば、上記のScheduling Jobの設定だけでなく、masterへのマージにより実行されるJobの設定がある場合、Scheduling jobで失敗となった後に、マージ時のjobが成功すると、それにより復旧したという通知が飛んでしまう。

これを回避するには、Scheduling Jobだけを実行するためのブランチを別途用意するか、CircleCIの通知機能は使わずSlackのAPIを直接叩くという回避策が考えられる。
前者はmasterブランチのコード中に設定が見えなくなってしまう問題があり、またmasterブランチの更新を取り込むためにjobの中でmasterをマージするような設定が必要になる。
また、通知機能により表示されるメッセージの文言は柔軟に設定できず、Jobの失敗内容もメッセージに表示したい場合などにも対応できない。
そのため、通知機能では要件を満たせず、SlackのAPIなどを直接叩かざるを得ないケースも多いだろう。

まとめ

CircleCIのSchedulingは便利ではあるものの、まだ実用性に乏しい感は否めないため、今後の改善を期待したい。