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などが勉強できたのでよしとする。