やりたいこと＆実行イメージ

今回は、こんな感じのことをやってみました。
参考にしたのはこちらです。
https://cloud.google.com/cloud-build/docs/automating-builds/run-builds-on-github?hl=ja

pullリクエスト時：　buildを実行
master への marge 時：　build & Cloud Run へ deploy を実行

はじめの準備

Cloud Run にUPするソース
連携するための GitHub リポジトリ　（今回はpublicのものです。）
GCPプロジェクト（課金が有効になっているもの）

※もちろん、無料お試し中でもできます！
GCPプロジェクトで Cloud Build、Cloud Run を有効にしておく

設定ファイルやソースの準備

以下、諸々の必要なファイルを作成して、連携対象のGitHubリポジトリにpushしておきます。
※そもそもcloudBuild.yamlファイルが存在しないと、CloudBuildが動かないのです・・・
以下を含めたソースはすべてGitHubにUPしてますので、必要に応じてご参照ください。
https://github.com/anyanco/CloudBuild-sample

CloudBuild 設定ファイル

プロジェクトフォルダの直下に以下の２つのファイルを作成しておきます。
今回は「cloudbuild-sample」という名前で Cloud Run サービスを作成します。

cloudbuild_build.yaml
cloudbuild_deploy.yaml

./cloudbuild_build.yaml

steps:
# Build the container image
- name: 'gcr.io/cloud-builders/docker'
  args: ['build',
         '-t',
         'asia.gcr.io/$PROJECT_ID/cloudbuild-sample:$SHORT_SHA',
         '.']

ここでは、Docker image を build するだけの設定を記載します。
-tコマンドでタグの設定をします。
$SHORT_SHAは、このbuildを実行するタイミングだけに割り振られるkeyだと思ってください。

cloudbuild.yaml の書き方の詳細は以下を参照ください。
https://cloud.google.com/cloud-build/docs/configuring-builds/create-basic-configuration?hl=ja

./cloudbuild_deploy.yaml

steps:
# Build the container image
- name: 'gcr.io/cloud-builders/docker'
  args: ['build',
         '-t',
         'asia.gcr.io/$PROJECT_ID/cloudbuild-sample:$SHORT_SHA',
         '.']

# Push the container image to Container Registry
- name: 'gcr.io/cloud-builders/docker'
  args: ['push',
         'asia.gcr.io/$PROJECT_ID/cloudbuild-sample:$SHORT_SHA']

# Deploy container image to Cloud Run
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['run',
         'deploy',
         'cloudbuild-sample',
         '--image',
         'asia.gcr.io/$PROJECT_ID/cloudbuild-sample:$SHORT_SHA',
         '--region',
         'asia-northeast1',
         '--platform',
         'managed',
         '--allow-unauthenticated']

images:
- asia.gcr.io/$PROJECT_ID/cloudbuild-sample:$SHORT_SHA

こちらは以下の３ステップの動作を行います。
　build → push → deploy
なお、pushでは Container Registry への push を表しています。
どこで何をやっているかは、コメントを参照ください。

Dockerfile

cloudbuild_~.yaml で build時に使用する Dockerfile が必要になります。
こちらの中身です。

./Dockerfile

# Use the official Golang image to create a build artifact.
FROM golang:1.14
# Create and change to the app directory.
WORKDIR /go/src
# Copy go.mod & go.sum
COPY go.* ./
# GoModuleを使うため、念の為 GO111MODULE をonにする.
RUN export GO111MODULE=on && go mod download
# 必要なもののみUP.
COPY ./app ./app
# app配下を実行ファイルに変換？
RUN go install ./app
# 実行
CMD ["/go/bin/app"]

その他

その他のmain.goなどの中身に関しては、こちらのGitHubリポジトリをご参照ください。

GitHub の設定

1.　以下のURLから、GitHub Marketplace にて、Cloud Build APIを有効にします。
　　　https://github.com/marketplace/google-cloud-build

こんな画面の下の方。。。
矢印のところをクリックします。
（こちらの画像では有効化済みのため、一部違うところがあるかも）

すると、こんな感じの表示になります。
アカウント名など、表示されている項目をよく確認して、ボタンをクリックします。
　　　

2.　ここで、連携対象のリポジトリを選択して、「Install」をクリックします。
　

※すでにAPIをインストール済みの場合は、こちらの設定から追加が可能です。

後はもろもろ設定があるかと思いますが、画面にしたがってポチポチしてください。
（キャプチャがあいまい・・・）
設定が完了すると、GCPプロジェクトに飛びます。

GCPプロジェクトの設定

GitHub側の設定が完了したら、次はGCPプロジェクトの設定を行います。
記載されているプロジェクト名、リポジトリ名が間違いない場合は「完了」をクリックします。
記載されているリポジトリ名が異なる場合は「編集」を、
プロジェクトが異なる場合は「＋別のプロジェクトを追加」をそれぞれクリックします。

「編集」をクリックした場合は以下のような画面になります。
対象のリポジトリ名を選択します。

問題なければ「リポジトリを接続」をクリックします。

この画面でトリガーを設定できそうなのですが、なぜかdefaultトリガーの作成しかできません。。。
上の「トリガー設定」リンクをクリックしても何も起きず。
というわけで、おとなしく「pushトリガーを作成」をクリックします。
（後で気づいたのですが、どうせdefaultトリガーを作成しても後から削除するなら、
「今回はスキップ」を選択しておくと、後から消す手間が省けましたね。。。）

するとこのように表示されるので、いったん「完了」をクリックしておきます。

そうすると、またGitHub側に戻ってきました。

これで GitHub と GCP の連携はいったん完了です。

トリガーの設定

では、先程は default のトリガーしか作成できなかったので、ちゃんとしたトリガーを設定します。

まず、GCPプロジェクトにて、メニューから
Cloud Build > トリガー
に遷移します。

ひとつだけ作成されているのが、先程の default トリガーです。
上部の「トリガーを作成」をクリックします。

以下の項目を入力していきます。
説明は必須ではないですが、入力しておくとわかりやすいです。
まずはじめに、pullリクエスト時にビルドを行うトリガーを作成します。

また、今回は pullリクエスト時と、marge時で異なる動作をさせたいため、
それぞれのタイミングで実行させたい cloudbuild_~.yaml を設定します。
入力できたら、「完了」をクリックします。

同様に、marge時のトリガーも作成します。
作成できたら、defaultトリガーはいらない挙動をしないよう、削除してしまいましょう。
（不安な場合は「無効」にしても大丈夫です。）

よくよく見ると、「ステータス」列の隣に「トリガーを実行」と記載されているものとされていないものがあります。
イベントが「pullリクエスト」となっている場合は実際にpullリクエストした場合でしか動かないのでしょうね、たぶん。

確認

ではここまでできたら、実際に確認していきます。

1.　ブランチを作成して、適当にmain.goに修正を加えます。
2.　１で行った修正をブランチにpushします。
3.　pullリクエストを作成します。
4.　以下のような感じでチェック結果がわかります。
　　緑のマークの上部分が CloudBuild の結果です。
　　下は GitHub側のチェックです。
　　履歴のところ、よく見ると、失敗したら✗になります。

５.　GCP側でもビルド状況を確認できます。
　　「メニュー」 > 「Cloud Build」 > 「履歴」
　　緑は成功、赤が失敗。
　　・・・いろいろ試行錯誤したんですよ。。。
　　

６.　Margeします。
　GitHub側はこんな状態です。
　

GitHub側にはCloudBuildのその後を知る術はないので、GCPに見に行きます。
　「メニュー」 > 「Cloud Build」 > 「履歴」
　最新が緑なので、成功したようです。
　

　次に、Container Registry に push されているかを確認します。
　ばっちりいます。
　ちなみに、このサービス名で登録するのが初めてであっても、勝手にフォルダが作られるので大丈夫です。
　

　最後は Cloud Run です。
　・・・ちょっと失敗しました。デプロイ先がおかしかったです。。。

　というわけで修正して動かし直しました。
　何回か失敗しているのはご愛嬌ということでｗ
　

　ビルドが成功しているのを確認できたら、Cloud Run にてサービスができているかのチェック。
　もともとこの名前のサービスはなかったのですが、無事、作成されていることを確認できました。

さいごに

　思ったより簡単に連携の設定ができました。
　トリガーも設定項目がわかりやすかったです。ただ、最初にデフォルトしか作成できないのは仕様なのでしょうか？
　（もしかしたら見逃してる？）
　トリガーに関しては、GitHubの操作をもっと細かく設定できそうなので
　（feature/~ で始まるブランチなら○○する、みたいな）
　この辺は設定次第でいろいろできそうです。

　あと、実際に仕事とかで使うならprivateリポジトリになりそうなので、この辺は要調査。