發佈到Cloud Run上的話，開發時基本上是以Tag的規則為依據。
Cloud Run的環境分成「開發(dev)」、「測試(stage)」、以及「正式(production)」三種環境。

注意:

• 使用SourceTree或其他UI進行git管理時，請不要將Tag拉回local。
• 請定期清理remote過期許久的Tag。

dev

dev環境的觸發條件設定：^\d+\.\d+\.\d+(a|b)\d+$
意思就是 版本號+(a或b)+流水號。

a代表的是alpha，b代表的是beta。
只要是符合這個條件的Tag都會被發佈到dev環境裡。
在Cloud Run的設定中，alpha會被build但不導流量，開發者需要自己去Cloud Run介面設定網址進行測試。
beta的話被build完成後就會接管目前所有流量。

stage

stage環境的觸發條件設定：^\d+\.\d+\.\d+s\d+$
意思就是 版本號+s+流水號。

只要符合這個條件的Tag就會被發佈到stage環境裡。

production

production環境的觸發條件為：^\d+\.\d+\.\d+$
意思就是 版本號。

cloudbuild.yaml範例

CloudBuild設定時可以建立替代變數，這個範例裡的 _SERVICE_NAME、_APP_ENV 皆是帶入的替代變數。
$PROJECT_ID、$TAG_NAME則是CloudBuild的內建變數。

steps:
  # 建立一個${_SERVICE_NAME}-${_APP_ENV}:$TAG_NAME的image，最後一個參數指向的是Dockerfile存在的目錄
  - name: 'gcr.io/cloud-builders/docker'
    args:
      [
        'build',
        '-t',
        'gcr.io/$PROJECT_ID/${_SERVICE_NAME}-${_APP_ENV}:$TAG_NAME',
        '.',
      ]

  # 將image推倒Container Registry
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/${_SERVICE_NAME}-${_APP_ENV}:$TAG_NAME']

  # 部署到Cloud Run
  # 以TAG_NAME以及_APP_ENV用來判斷是否需要導流
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: bash
    args:
      - '-c'
      - |
        tag=$TAG_NAME
        gcloud run deploy ${_SERVICE_NAME}-${_APP_ENV} --image=gcr.io/$PROJECT_ID/${_SERVICE_NAME}-${_APP_ENV}:$TAG_NAME --revision-suffix=v${tag//./-} --set-env-vars "APP_ENV=${_APP_ENV}" --region=asia-east1 --platform=managed --allow-unauthenticated --no-traffic
        if [ "$TAG_NAME" =~ ^[0-9]+\.[0-9]+\.[0-9]+(s](/mahudas-tw/hive/wiki/b)[0-9]+$-||-"${_APP_ENV}"-==-"production"-); then 
          gcloud run services update-traffic ${_SERVICE_NAME}-${_APP_ENV} --region=asia-east1 --to-latest
        fi
timeout: 3000s
images:
  - 'gcr.io/$PROJECT_ID/${_SERVICE_NAME}-${_APP_ENV}:$TAG_NAME'