ソースコードを変更するたびに、Cloud Build トリガーが自動的にビルドを開始します。ソース リポジトリが変更された場合や、特定の条件に一致する変更があった場合にコードをビルドするようにトリガーを構成できます。
このページでは、GitHub や Bitbucket などのソース リポジトリに接続し、リポジトリにコードをビルドするビルドトリガーを作成する方法について説明します。
始める前に
- Cloud Source Repositories、GitHub または Bitbucket にソースコードが必要です。
Dockerfile
または Cloud Build 構成ファイルのいずれかが必要です。
ソース リポジトリに接続する
リポジトリにコードを作成する前に、Cloud Build をソース リポジトリに接続する必要があります。Cloud Source Repositories のリポジトリはデフォルトで Cloud Build に接続されます。手動で接続しなくても、Cloud Source Repositories にリポジトリのトリガーを作成できます。GitHub と Bitbucket に接続するには、次の操作を行います。
Google Cloud Console で [トリガー] ページを開きます。
プロジェクトを選択し、[開く] をクリックします。
[リポジトリを接続] をクリックします。
ソースコードを保存したリポジトリを選択します。
ソース リポジトリとして [GitHub(ミラーリング済み)] または [Bitbucket(ミラーリング済み)] を選択すると、Cloud Build は Cloud Source Repositories にリポジトリをミラーリングし、すべてのオペレーションにミラーリング済みのリポジトリを使用します。
[続行] をクリックします。
ユーザー名とパスワードを使用して、ソース リポジトリに対する認証を行います。
使用可能なリポジトリのリストからリポジトリを選択して、[接続] をクリックします。
GitHub や Bitbucket などの外部リポジトリを使用するには、作業中の Cloud プロジェクトでオーナーレベルの権限が必要になります。
リポジトリのソースコードを自動的にビルドするビルドトリガーの作成を続けるには、[トリガーを作成する] をクリックします。継続しない場合は [完了] をクリックします。
ビルドトリガーの作成
Console
Google Cloud Console で [トリガー] ページを開きます。
ページの上部にあるプロジェクト セレクタのプルダウン メニューからプロジェクトを選択します。
[開く] をクリックします。
[トリガーを作成] をクリックします。
次のトリガー設定を入力します。
名前: トリガーの名前を入力します。
説明(省略可): トリガーの説明を入力します。
イベント: トリガーを起動するリポジトリ イベントを選択します。
ブランチに push する: 特定のブランチに対して commit が行われたときにビルドを開始するトリガーを設定します。
新しいタグを push する: 特定のタグを含む commit が行われたときにビルドを開始するトリガーを設定します。
pull リクエスト(GitHub アプリのみ): pull リクエストの commit が行われたときにビルドを開始するトリガーを設定します。この機能は、GitHub アプリトリガーを作成する場合にのみ使用できます。GitHub アプリトリガーの作成方法については、GitHub アプリトリガーの作成をご覧ください。
ソース: リポジトリと、イベントの監視対象となるブランチまたはタグを選択します。
- リポジトリ: 使用可能なリポジトリのリストから目的のリポジトリを選択します。新しいリポジトリに接続するには、ソース リポジトリへの接続をご覧ください。
ビルドが実行されると、Cloud Build で使用されるデフォルトの作業ディレクトリである
/workspace
にリポジトリの内容がコピーされます。作業ディレクトリの詳細については、ビルド構成の概要ページをご覧ください。- ブランチまたはタグ: ブランチまたはタグの値にマッチングさせる正規表現を指定します。有効な正規表現の構文については、RE2 構文をご覧ください。
含まれるファイル(省略可): 少なくとも 1 つのファイルに影響する変更があった場合は、ビルドが開始されます。glob 文字列で、ワイルドカード文字を使用して複数のファイルを指定できます。使用できるワイルドカード文字は、Go Match でサポートされる文字、
**
、オルタネイションなどです。無視されるファイル(省略可): 無視されるファイルにのみ影響する変更があった場合は、ビルドが開始されません。glob 文字列で、ワイルドカード文字を使用して複数のファイルを指定できます。使用できるワイルドカード文字は、Go Match でサポートされる文字、
**
、オルタネイションなどです。含まれているファイルと無視されるファイルの両方で同じファイルを指定した場合、そのファイルを変更してもビルドは呼び出されません。たとえば、すべてのディレクトリ内の
README.md
を無視するために無視されるファイルに**/README.md
を指定し、src/
フォルダ内の任意のファイルへの変更でビルドを開始するために含まれているファイルにsrc/*
を指定したとします。ここで、src/README.md
に変更を加えた場合、Cloud Build はビルドを開始しません。変更をソースに push するたびに、Cloud Build は変更されたファイルについて、含まれているファイルと無視されるファイルを検索し、ビルドを呼び出すかどうかを決定します。- 既存のブランチのリポジトリに変更を push した場合、Cloud Build は push したばかりの commit と以前にそのブランチが指していた commit の間で、変更されたファイルを調べます。
- 新しく作成したブランチに変更を push した場合、Cloud Build はリポジトリ内のすべてのファイルを変更されたファイルとして扱います。
- ブランチを削除した場合、Cloud Build はビルドを開始しません。
ビルド構成: Cloud Console でインライン ビルド構成ファイルを作成するか、ビルドで使用するビルド構成ファイル(リモート リポジトリにあるファイル)を選択します。
ビルド構成に
Dockerfile
を使用するには、Dockerfile ディレクトリと生成されるイメージの名前を指定する必要があります。ビルドのタイムアウトを指定することもできます。Dockerfile
とイメージ名を指定すると、ビルドが実行されるdocker build
コマンドのプレビューが表示されます。ビルド構成にビルド構成ファイルを使用するには、ビルド構成ファイルの場所を指定する必要があります。
代入変数(省略可): ビルドの構成オプションとして Cloud Build 構成ファイルを選択した場合、このフィールドを使用して、トリガー固有の代入変数を定義できます。たとえば、複数のトリガーを作成し、それぞれのトリガーが特定の環境にアプリをデプロイするとします。この場合、アプリケーションが 1 つの環境にデプロイされることをビルド構成ファイルに指定し、このフィールドを使用して代入変数を定義して、このトリガーがデプロイされる環境を指定できます。ビルド構成ファイルに代入値を指定する方法については、変数値の置換をご覧ください。
[作成] をクリックして、ビルドトリガーを保存します。
gcloud
ソースコードが Cloud Source Repositories にある場合にトリガーを作成するには:
gcloud beta builds triggers create cloud-source-repositories \
--repo=[REPO_NAME] \
--branch-pattern=".*" \
--build-config=[BUILD_CONFIG_FILE] \
ここで
--repo
はリポジトリの名前です。--branch-pattern
はトリガーのタイプです。文字列として指定します。上記の例では、".*",
を指定しています。リポジトリの任意のブランチに変更が push されたときにビルドがトリガーされます。また、--tag-pattern
を使用して、特定のタグに push された場合にのみビルドがトリガーされるように指定することもできます。--build-config
はビルド構成ファイルのパスです。
フラグの一覧については、gcloud
リファレンスで Cloud Source Repositories のトリガーを作成する方法をご覧ください。
ソースコードが GitHub にある場合にトリガーを作成するには:
gcloud beta builds triggers create github \
--repo-name=[REPO_NAME] \
--repo-owner=[REPO_OWNER] \
--branch-pattern=".*" \
--build-config=[BUILD_CONFIG_FILE] \
ここで
--repo-name
はリポジトリの名前です。--repo-owner
はリポジトリのオーナーの名前です。--branch-pattern
はトリガーのタイプです。文字列として指定します。上記の例では、".*",
を指定しています。リポジトリの任意のブランチに変更が push されたときにビルドがトリガーされます。--tag-pattern
を使用して、特定のタグに push されたときにのみビルドがトリガーされるように指定することもできます。また、--pull-request-pattern
を使用すると、すべての pull リクエスト イベントが Git ベースブランチと照合されることを指定できます。--build-config
はビルド構成ファイルのパスです。
フラグの一覧については、gcloud
リファレンスで GitHub のトリガーを作成する方法をご覧ください。
Cloud Source Repositories または GitHub を使用して gcloud
コマンドを実行してトリガーを作成すると、次のような出力が表示されます。
NAME CREATE_TIME STATUS
trigger-001 2019-10-30T20:45:03+00:00
ビルドトリガーのテスト
ビルドトリガーを手動でテストするには:
Google Cloud Console で [トリガー] ページを開きます。
リストからトリガーを選択して、[トリガーを実行] をクリックします。
ビルドトリガーのスキップ
ソースコードを変更したときにビルドを実行したくない場合もあります。たとえば、ドキュメントや構成ファイルを更新したときに、ビルドを呼び出したくないことがあります。
このようなシナリオでは、[skip ci]
または [ci skip]
を commit メッセージに追加すると、ビルドは呼び出されません。
後の commit でビルドを実行する場合は、[トリガー] ページの [トリガーを実行] ボタンを使用します。
ビルドにリポジトリの履歴を含める
Git リポジトリでソースをビルドするために、Cloud Build はリポジトリのシャロー クローンを実行します。つまり、ビルドを開始した単一の commit だけが、ビルドするワークスペースにチェックアウトされます。Cloud Build は他のブランチや履歴をチェックアウトしません。これは効率と高めるために行われるため、ビルドで単一の commit をビルドするためにリポジトリ全体と履歴のフェッチを待機する必要はありません。
リポジトリの履歴を追加してビルドに含める場合は、ビルド構成ファイルにビルドステップを追加して、クローンの「シャローを解除」できます。例:
steps:
- name: gcr.io/cloud-builders/git
args: ['fetch', '--unshallow']
...
git fetch
の詳細については、git のリファレンスをご覧ください。ビルド構成ファイルの作成方法については、ビルド構成の概要をご覧ください。
ビルドトリガーを無効にする
Console
Google Cloud Console で [トリガー] ページを開きます。
ページの上部にあるプロジェクト セレクタのプルダウン メニューからプロジェクトを選択します。
[開く] をクリックします。
無効にするトリガーの行を見つけます。
行の右端にあるメニュー(丸が縦に並んだアイコン)をクリックします。
[Disable] を選択します。
gcloud
トリガーを無効にするには:
無効にするトリガーをエクスポートします。
gcloud beta builds triggers export [NAME] --destination=[PATH]
ここで
[NAME]
はトリガーの名前です。[PATH]
は、トリガーをエクスポートする先のファイルパスです。たとえば、ファイルパスはexamples/trigger.yaml
として指定できます。トリガーのファイル名の拡張子は.yaml
である必要があります。
エクスポートしたトリガーを含むファイルを開きます。
ファイルは次のようになります。
createTime: '2020-02-21T20:02:50.215599013Z' description: Push to any branch filename: cloudbuild.yaml github: name: example-repo-name owner: example-owner push: branch: .* id: example-id name: Push-to-any-branch tags: - github-default-push-trigger
ファイルの末尾に
disabled
フィールドを追加し、値をTrue
に設定します。disabled: True
ファイルを保存します。
トリガーをインポートします。
gcloud beta builds triggers import --source=[PATH]
ここで
[PATH]
は、インポートするトリガーのファイルパスです。
これで、ビルドトリガーが無効になりました。
トリガーを無効にしても、トリガーは削除されません。トリガーを削除するには、ビルドトリガーを削除するをご覧ください。トリガーを再度有効にするには、ステータスを [有効] に変更します。
ビルドトリガーを削除する
Console
Google Cloud Console で [トリガー] ページを開きます。
ページの上部にあるプロジェクト セレクタのプルダウン メニューからプロジェクトを選択します。
[開く] をクリックします。
削除するトリガーの行を探します。
行の右端にあるメニュー(丸が縦に並んだアイコン)をクリックします。
[削除] を選択します。
gcloud
トリガーを削除するには、次のコマンドを実行します。
gcloud beta builds triggers delete [NAME]
ここで
[NAME]
はトリガーの名前です。
フラグの一覧については、gcloud
リファレンスでトリガーの削除方法をご覧ください。
ビルドトリガーのセキュリティへの影響
ビルドトリガーは Cloud Build アカウントを使用してビルドを実行します。これにより、トリガーを使用してビルドを実行するユーザーにビルド時の権限が付与されます。ビルドトリガーを使用する場合は、次のセキュリティ上の影響に注意してください。
- Cloud プロジェクトへのアクセス権はないが、プロジェクト内のビルドトリガーに関連付けられたリポジトリへの書き込みアクセス権があるユーザーは、ビルドされるコードを変更する権限を持ちます。
- GitHub pull リクエスト トリガーを使用している場合は、リポジトリへの読み取りアクセス権を持つすべてのユーザーが pull リクエストを送信できます。これにより、pull リクエスト内のコードの変更を含むビルドが実行される可能性が生じます。GitHub pull リクエスト トリガーでこの動作を無効にする方法については、GitHub アプリトリガーの作成をご覧ください。
Cloud Build サービス アカウントとそれに関連付けられた権限の詳細については、Cloud Build サービス アカウントをご覧ください。
次のステップ
gcloud
コマンドライン ツールを使用してビルドを呼び出す方法を学習する。- 手動でビルドを開始する方法を確認する。
- 手動トリガーを作成して、手動呼び出しが必要なデプロイを設定する方法を学習する。
- ビルドトリガーのビルド結果を表示する方法を学習する。
- GitHub アプリトリガーの作成方法を学習する。