Github Action、Cloud Buildなど試したがが・・・

Cloud Buildはバグがあるようで行き詰りました。
Guthub Actionsといってもコミット前に

credential省略などちゃんGoogle Cloud環境上特有の設定周りについてもエラーがない状態を確認してからcommitしたい
イベントトリガーで繋げるようなFunctionsはdeploy後に挙動を確認したい

など、つまり実際にDeployして最終確認してからレポジトリを汚したいこともあり、違うなと。

.batファイルで可読性を保ちながら流用

gcloudなら実例が比較的多いし、Actionsと違ってcommit前に実際にデプロイしてみて確認するが容易。
ただし、いちいちPowerShellに記述していくのも面倒なので、バッチにしてついでにレポジトリにも混ぜて誰でもダブルクリックで利用できるようにしてみた。

deploy.bat

REM ファイルのカレントディレクトリに移動
cd /d %~dp0

REM 筆者の都合上インスタンスを1に絞っている
REM とあるバケットのdeleteをトリガーにしている

gcloud functions deploy FUNCTION_NAME ^
--region=asia-northeast1 ^
--entry-point MAIN_FUNC_NAME ^
--runtime python39 ^
--trigger-resource=BUCKET_NAME ^
--trigger-event google.storage.object.delete ^
--set-env-vars=ENV_KEY=ENV_VAL ^
--max-instances=1 ^
--min-instances=0 ^
--retry ^
--timeout=540 ^
--ignore-file=.gcloudignore

中央集権的な管理方法ではないが、個人レベルや、特に開発初期の段階では非常に便利なので、この方法に落ち着いて大満足。

.gcloudignoreを忘れないように

Functions構成フォルダと同じディレクトリにbatファイルを置く場合は(そうじゃなくても__pycashe__/あるし).gcloudignoreを、そしてそこにバッチファイルを含めることを忘れないように。

.gcloudignore

deploy.bat
__pycache__/
.gcloudignore

あとがき

バッチファイルにしてみて、これが本来の用途だったということに気づいた。そうっすよね、みんな一々イチからこんなに細かくコマンド書きませんよね。別にCLIもバッチも初めてじゃないのになんで気づかなかったんだろう・・・。
「Cloud Functionsのソース更新面倒くせ〜」からCI/CDに行ってしまって迷走した。self-taughtな開発者の虚しい逡巡。
しかし、yamlなどが勉強できたのでよしとする。