Cloud Build「build step exited with non-zero status:」は直前のコマンドが失敗したという意味

クラウドエースの亀梨です。自分では常識だと思っていても、案外、世間ではそうでもなかったりするようです。

エラーメッセージの検索結果が適切でないように見える

Google: "build step exited with non-zero status: 2"

この記事を執筆している時点では、いくつかのブログと Q & A サイトによって、このエラーメッセージの解説記事が提供されています。
何が問題なのか。それは、書かれている内容が「コマンドの戻り値」について、まったく言及していないことです。
つまり、誤った解釈の「回答」だけがこの検索結果に表示されている、ということです。
同じことで苦しむ人がいなくなるように、この記事を書きます。

この記事で伝えたいことの概要

1. Cloud Build は、Docker コンテナをステップ毎に起動して、コマンドを実行するツールです。
2. Unix や Linux では、コマンドラインの終了ステータスとして zero を正常、 non zero をそれ以外と扱うことが多いです。 (これは Unix ライク OS 一般の作法です)
3. Cloud Build もそれに倣っており、デフォルト動作として Docker コンテナ上のコマンドラインが non zero で終了した場合は、そのステップをエラーとして扱い停止します。その結果、このメッセージが記録されます。

メッセージを読み解く背景 Unix 系コマンドの戻り値

Cloud Build は、あらかじめ cloudbuild.yaml に記述したシェルスクリプトを Docker コンテナに渡して、各ステップを実行するサービスです。（ちょっと語弊がありますが）

Docker コンテナというのは、元々はLinux カーネルの機能を前提にしたもので（※現在はWindowsコンテナも存在します）、Linux は元々、 Unix互換として動作するよう開発されています。
Cloud Build の step は、この Docker コンテナの実行を、それぞれひとつの Unix コマンドのように扱います。
Unix コマンドの世界では、コマンドは全て戻り値（ステータスコード）を持ちます。一般的には、ゼロが成功であり、ゼロ以外は失敗です。（※ grep など、ステータスコードがこの法則に従っていない例外も一部存在します。）
Cloud Buildでは、この法則に倣って、コンテナ内のコマンドが最後に返したステータスコードをもって、ステップの成否を判断しています。

ここまではいいでしょうか。
では、あらためて、元のエラーメッセージを見てみましょう。

build step exited with non-zero status: 2

直訳すると、「ビルドステップが、終了した。ゼロではないステータスコード、2とともに」でしょうか。

お分かりになりましたでしょうか。
ビルドステップが、ゼロではないステータスコードで終了したのです。
ビルドステップ = Unix コマンド と考えてください。
つまり、このエラーメッセージは、「ビルドステップが失敗したよ」と言っているのです。ビルドステップが失敗した、という事実しか告げていないのです。

どう対処すれば？

このログのほんの少し上、一行か二行上のエラーメッセージを読んでください。そこに答えが書いてあります。
このメッセージが出ているビルドステップで実行したコマンドの戻り値が「2」となるようなエラーがそこで起きたために、Cloud Build がビルド処理をやめた、というのが真相です。