ぼくのかんがえたもっとさいきょうのでぷろい

昨日 ぼくのかんがえたさいきょうのでぷろい を実装したんだけど、その後、残っていた残課題に対応しているうちにもっと最強のデプロイ方法があることに気付いた。結論から言って GitHub Deployments を使う必要がなかった。GitHub Deployments で過去のリビジョンを指定したときは次のような 409 エラーが発生する。

gh: Conflict merging main into f0cff65c94c4a242efebc79c8fb1e31d58d2f592. (HTTP 409)

これを回避するためにどんな手段があるかなと workflow dispatch event をみていて inputs というパラメーターがあることに気付いた。あれ?workflow dispatch ってパラメーターを受け取ることができたんだっけ?と調べたら2020年7月ぐらいからできるようになってた。

github actions の web ui とも連動していて画面からもパラメーターを渡せるようになっていた。jenkins で言うところのパラメーター付きビルドと呼ばれる機能。カスタムアクションの inputs と同じような使い勝手で利用できる。workflow dispatch がパラメーターを受け取れるなら GitHub Deployments を使うメリットって何があるっけ?と思ったら何もなかった。GitHub Deployments を使うことで無駄にリソースを浪費してパイプライン処理を複雑化させるデメリットしかなかった。inputs に渡す型に environment を指定すると、環境の制限や権限、protected branch などにも応用できるらしい。但し、この environment は public リポジトリか、github enterprise でしか高度な設定はできないみたい。GitHub Deployments 経由でリソースの作成自体はできる。