こんにちは。てぃろです。
今回はCloud Buildのビルド結果を通知するためにいろいろ調べたので、それをまとめておきます。
また、Slackへの通知メッセージをカスタマイズしたので、それをご紹介しようと思います。
Cloud Buildの通知は公式のソースをカスタマイズして使おう
Google Cloud公式からCloud Buildの通知をするために使えるソースやその使い方が公開されていますので、それを使っていくのが一番手っ取り早いです。
しかし、これをそのまま使うと、ちょっと使い勝手が悪いというのは本当のようです。調べてみると、多くの方々がいろいろなカスタマイズを紹介されていました。
ただ、今回特に参考にさせてもらったのはこちらの２つの記事でした。
まず１つ目の記事については、公式ドキュメントでは少し分かりづらい部分をわかりやすく解説してもらっていたのが一番参考になったポイントですね。いくつかカスタマイズについても参考にさせてもらいました。
２つ目の記事については、主に通知メッセージのカスタマイズで参考にさせてもらいました。これについては私のカスタマイズ結果も合わせて後述します。
公式ソースの構成と理解するポイント
公式のソースによる通知の構成は、先程紹介した１つ目の記事の冒頭で図とともに紹介されています。
SlackのIncoming Webhookを呼び出すだけの簡単なものではあるものの、各種設定やメッセージのテンプレートを分離させるなど結構な工夫が施されています。
詳細は公式ドキュメントにも書いてありますが、ソースや図を見ていてもわかりにくい部分があったので、その点を書き出しておきます。
Pub/Subのトピックは必ずcloud-builds
この公式ソースはデプロイするだけで通知をさばき始めますが、よく考えるとCloud Buildの構成に何も手を入れなくても使えます。
これはなぜかというと、Cloud Buildは暗黙的にPub/Subの cloud-builds というトピックにメタデータをパブリッシュしているということでした。そのため、トピックをその名前で作るだけでCloud Buildの実行に関するメタデータを取得することができるということなのです。
Slack通知メッセージは、Block kitで書かれている
上図にはないのですが、今は slack.json というファイルもCloud Storageにアップロードされて使われるようになっています。（おそらく記事が書かれた頃にはこのテンプレートがなかったのかも）
このJSONファイルは、Slackでリッチなメッセージを作成するために使われるテンプレートで、Slackが公式に提供している機能です。公式ではその作成のためのシミュレータも用意されているので、カスタマイズがすごくわかりやすくできるようになっています。
シミュレータにはこちらからアクセスしてみてください。
Slack通知メッセージのために参照できるパラメータにBuild.XとParams.Xの２種がある
後述もしますが、Slack通知メッセージの中にCloud Buildのメタデータを載せようとしたときに変数の参照をすることで実現ができます。
公式のドキュメントはこちらです。
リポジトリ名やブランチ名などの情報も取得できますが、これらはそのまま Build.X で参照することはできません。
Params.X で参照できるように、設定で変数の参照を設定することが必要です。参考にした２つ目のブログで具体的な設定方法が紹介されていますが、それを抜粋すると以下の箇所です。
spec:
notification:
params:
buildStatus: $(build.status)
buildTriggerName: $(build.substitutions['TRIGGER_NAME'])
buildRepository: $(build.substitutions['REPO_NAME'])
buildBranch: $(build.substitutions['BRANCH_NAME'])
buildCommit: $(build.substitutions['COMMIT_SHA'])このように build.substitutions を使って参照するように設定します。これを slack.json で参照するときには、 Param.X で参照するというわけです。
ぱっと見では、BuildとParamはちょっとわかりにくいので、もしデプロイが失敗しているようならコピペなどで混ざってしまっていないかとか確認してみるといいと思います。
Cloud Runのデプロイが失敗したときのポートに関するエラーメッセージはデタラメ
デプロイに失敗したときにポートが開いていませんのようなメッセージが出ることがあります。よく考えればわかるのですが、今回の構成ではCloud Runは外部からHTTPリクエストを受け付けるようにはできていないので、それがデプロイ失敗の原因なわけがありません。
これは参考にした１つ目の記事の最後の方でも言及されていて、非常に参考になりました。
要するに失敗するとほぼこのメッセージが出るのですが、きちんとCloud Runのログそのものを確認することで本当の原因はわかるということでした。デプロイに失敗したと思ったらきちんとCloud Runのログのほうを確認するようにしましょう。
カスタマイズ結果
ここまで通知を使うためのポイントを説明しましたが、ここからは最終的なSlack通知メッセージのカスタマイズ結果をお見せします。早速ですが、 slack.json は以下のとおりです。
[
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": "*{{.Params.buildTriggerName}}* is *{{.Params.buildStatus}}*"
}
},
{
"type": "divider"
},
{
"type": "context",
"elements": [
{
"type": "mrkdwn",
"text": "Project ID\n*{{.Build.ProjectId}}*"
}
]
},
{
"type": "context",
"elements": [
{
"type": "mrkdwn",
"text": "Repository\n*{{.Params.buildRepository}}*"
},
{
"type": "mrkdwn",
"text": "Branch\n*{{.Params.buildBranch}}*"
}
]
},
{
"type": "actions",
"elements": [
{
"type": "button",
"text": {
"type": "plain_text",
"text": ":notebook: View Build Logs",
"emoji": true
},
"value": "click_me_123",
"url": "{{.Build.LogUrl}}",
"action_id": "button-action-0"
},
{
"type": "button",
"text": {
"type": "plain_text",
"text": ":computer: View Commit",
"emoji": true
},
"value": "click_me_123",
"url": "https://github.com/<ORGANIZATION NAME>/{{.Params.buildRepository}}/commit/{{.Params.buildCommit}}",
"action_id": "button-action-1"
}
]
}
]このレンダリング結果は以下のとおりです。
次になぜこんなメッセージにしたのか理由を説明しておきます。
どんなビルドか動いたか？知りたい
通知の中身で表示している情報は、どのプロジェクトのどのアプリのどの断面がビルドされたのかわかるようにしたいのでこれらの情報を出すことにしました。でも、正直バッチリ目立たせたいのはトリガー名。これがわかればチャンネル名も含めて何かわかりそうなもの。なのでそれ以外の情報は目立たないようにしました。
通知で成功しても失敗しても見たいのは、ビルドログとCommit内容
通知を見てどうしたいか？というと、何が成功してどんな結果になったのか？失敗してしまった場合にはなぜなのか？というのを知りたい。そのためにはBuildのログも見たいし、そのトリガーになったCommit結果も見たい場合がある。なので、その２つのリンクに飛べるようにしました。
最後に
今回はCloud Buildの結果通知に関してポイント解説とメッセージカスタマイズの例を示しました。
通知はすればいいというものでもないし、情報をたくさん出せばいいというものでもありません。適切な量の情報を出さないとややこしくて結局見なかったりします。
しかし、次のアクションにつながる仕掛けがあれば生産性はすごく上がるというものでもあり、工夫のしがいがあります。今後もこういう小さい工夫はたくさんしていこうと思います。
