GitHub Actions でSlackに通知するいくつかの方法を比較してみた
前回の続きです。
なんとなく採用した rtCamp/action-slack-notify はActions自体のビルドにそこそこ時間を要してしまうことから、Privateリポジトリで使いまくると思わぬ課金対象になる可能性があります。そんなわけで、できるだけ短時間で実行できるActionsを探したいと思います。
Slack通知するGitHub Actions一斉比較
Actionsのピックアップ
GitHubのMarketplaceからStarがたくさんついてそうなActionsをいくつかピックアップしました。それぞれ設定して一斉に走らせてみて、どのくらい実行時間が違うか比較してみます。こういう時、並列にジョブを実行できるGitHub Actionsは便利です。
- rtCamp/action-slack-notify@v2.0.0
 - Ilshidur/action-slack@master
 - homoluctus/slatify@master
 - 8398a7/action-slack@v3
 
各Actionsで設定項目は少しずつ違いますが、とりあえずWebhook URLがあれば動きます。
比較結果
ガチンコ対決した結果はこちら。
| Actions | 実行時間 | 
|---|---|
 rtCamp/action-slack-notify@v2.0.0  | 
52 sec | 
 Ilshidur/action-slack@master             | 
29 sec | 
 homoluctus/slatify@master                | 
4 sec | 
 8398a7/action-slack@v3                    | 
2 sec | 
多少のバラつきはあれど、 homoluctus/slatify@master と 8398a7/action-slack@v3 が大体2〜4秒で動作しました。圧倒的に高速。。!
中でも 8398a7/action-slack@v3 はSlackのMessage Payloadをそのまま記述できるため、送信したいメッセージフォーマットを自由に構成できます。というわけで 8398a7/action-slack@v3 がええやん!となりました。
コレで勝つる!と思った矢先に
色々比較して一番高速で自由度も高いActionsを選定できた!やったぜ!と喜んでいたところに、弊社エンジニアの @shogo82148 より次のような指摘が入りました。

確かに出てる!node.js全くわからないマンなのでWebで色々調べてみたところ、どうやらnode.js 10.x から非推奨になっているメソッドがあると出る警告のようです。
で、件のActionsを調べてみたらすでにmasterブランチでは修正が取り込まれているようでした。
ただし安定版のリリースにはまだ含まれていないようで、なんだかなーといった感じ。そんな感じで調べてると次のようなツッコミが入ります。
やはり信じられるのは curl と jq ...
curl と jq で書くSlack通知
ということで、結局他の人が作ったActionsには一切頼らず、 jq コマンドと curl コマンドで直接Incoming WebhookをPOSTする方法に切り替えてみました。
幸い、GitHub Actionsで使用できるUbuntuには最初からどちらのコマンドもインストールされているので、実行したいコマンドを記述するだけで実現できます。
name: notify on: pull_request: types: ['closed'] paths: - 'webapi/swagger/**' branches: - master jobs: notify: name: Slack Notification runs-on: ubuntu-latest steps: - name: 'Send Notification' run: | jq -n '{ attachments: [{ pretext: "Swagger が更新されたよ!", color: "good", title: "${{ github.event.pull_request.title }}", title_link: "${{ github.event.pull_request.html_url }}" }] }' | curl -H 'Content-Type: application/json' -d @- ${{ secrets.SLACK_WEBHOOK }}
実行結果はこんな感じです(↑の設定例と若干差異がありますが許して。。)

気になる実行時間はこちら。

なんと1秒!Actionsをセットアップするオーバーヘッドがゼロなので、そりゃそうだという感じです。いい感じ!
というわけで
jq と curl を使う方法に切り替えることで、無事Actionsを高速化することができました。実測値で約60倍!
また、この方法もMessage Payloadを直接記述しているので、自分が通知したいメッセージのフォーマットを自由に構成できます。
これでイケるやろ、と思った矢先、またしても @shogo82148 より次のようなツッコミが入ります。
そういえばこれって Pull Request Title Injection できないですかね? まあ、タイトル書くの社員なのでいいんですが。
続く。。