コンテンツに移動
デベロッパー

「git deploy」によるコードのプッシュとターミナルでのビルド処理の表示

2021年9月28日
Google Cloud Japan Team

※この投稿は米国時間 2021 年 9 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

Heroku などのホスティング サービスでは、「git push heroku main」を実行すればコードのプッシュ、ビルド、デプロイが行われます。このようなユーザー ワークフローに慣れている人も多いでしょう。リモートの Git サーバーがコードを受け取ると、ビルドが開始されるのです。

Cloud Build のソースベースのビルドトリガーでも同様のことが行えるようになっており、「git push」でコードをプッシュすればビルドが開始されます。ただし、git push コマンドを実行した際に、実際のビルド処理の内容が表示されることはありません。

Heroku を使用する場合と同じように使えるコマンドはないのでしょうか。

実は、git deploy というコマンドがあります。これは小さな Python スクリプトで、コマンド単体でコードをプッシュし、ビルド処理を表示することが可能です。

このコマンドのコードは https://github.com/glasnt/git-deploy から取得できます。

このコード自体はビルド処理などは行わず、Cloud Build での実行内容を表示するだけのコマンドです。

では、このコマンドの動作について説明するうえで、まず Git の仕組みと Cloud Build のトリガーの仕組みについて触れておきましょう。

Git フック

フックとは、Git でなんらかのアクションが発生した際に実行されるカスタム スクリプトです。クライアントサイドとサーバーサイドという 2 つのカテゴリがあります。クライアントサイド フックを設定する場合であれば、希望する Linter を実行する .git/hooks/pre-commit ファイルを作成して、コミット メッセージを書く前に lint チェックを行うことができます。

一方、サーバーサイド フックの場合は、サーバー上に保存する必要があります。Git が返すログに「remote: 」というプレフィックスが付いていれば、サーバーサイド フックが実行されたことがわかります。Heroku では、サーバーサイド フックを使ってデプロイを開始しているのですが、GitHub でもサーバーサイド フックを使用しています。ブランチをリポジトリにプッシュするとブランチでプルリクエストを作成する際に使用できるリンクが返されます(例: remote: Create a pull request for 'mytopic' on GitHub by visiting)。

しかし、デベロッパーの場合は GitHub の Git サーバーを管理することができず、サーバーサイド フックを作成できません。そのため、今回のケースには適していません。そこで、マシンの側で Git を拡張します。

Git の拡張機能

Git の拡張機能は非常に簡単に用意できます。Git を変更する必要はなく、Git により自動的にスクリプトが検出されます。

Git でコマンドを実行すると、そのコマンドが内部に組み込まれた機能なのかどうかが最初にチェックされます。コマンドが組み込まれているものでない場合には、「namespace」内に外部コマンドがあるかチェックされ、それが実行されます。具体的には、「git-」で始まるシステム PATH(例: git-deploy)上に実行可能ファイルがある場合、「git deploy」を呼び出すとそのスクリプトが実行されます。このようなシンプルな仕組みであることから、Git 上での操作感を保ったまま、Git のワークフローを拡張することが可能です(拡張されているように感じられます)。

コマンドラインで Cloud Build について確認する

Cloud Build は、Cloud Console 内に充実した独自のユーザー インターフェースを備えており、Cloud Run などのサービスにネイティブに統合されています。一方、Google Cloud のコマンドラインである gcloud にも充実したインターフェースが用意されており、そのような機能の一例に gcloud builds log --stream があります。これはビルド処理の進捗を Google Cloud Console 上で閲覧しているかのように表示するものです。

また、gcloud を使用して Cloud Build のトリガーをリストアップし、GitHub のオーナー、名前、ブランチなどで絞り込むこともできます。この一意のトリガー ID を使用することで、現在実行中のビルドを確認してストリーミングすることも可能です。GitHub の識別情報は、Git の設定済みリモートソースおよびブランチを調べることで入手できます。

すべてを組み合わせる

では、ここまでの説明をふまえて、git deploy スクリプトの動作について解説しましょう。git deploy では、現在のフォルダに基づいて、設定済みのブランチとリモートソースが検出されます。次に、プッシュされたコードが実行されます。その後、リモートソースに関連付けられている Cloud Build トリガーが確認され、そのトリガーの起点となるビルドが開始されるまで待機します。ビルドが開始されると、ログがターミナルにストリーミングされます。

このように、このスクリプトはそれ自体では何も実行せず、発生した内容だけをターミナル上に表示するのです。✨

(このスクリプトを Python で記述しているのは、正規表現パーサーを Bash で記述するのを避けたかったためです。Bash で記述した場合、他のシェルを使うユーザーの役には立ちません。Git の拡張機能はどの言語でも記述できます。)

-Developer Relations シニア エンジニア Katie McLaughlin

投稿先