1については反対だな。シェル以上のものが必要になると、ちょっと臭いがする。ビルドやテストのプロセスは、もっとシンプルであるべきだと思う。

ステップ0. 意図的に時間を無駄にするCIサービスは使わないで、「SSHで再ビルド」みたいな機能があるCIサービスを使おう。前の議論から見ると（https://news.ycombinator.com/item?id=46592643）、Semaphore CIはまだそれを提供しているみたいだね。

アクションでの永続状態はどう扱ってる？私のアクションでは、依存関係をゼロからインストールするのに一番時間がかかるんだ。それを早くしたいけど、どうやっても分からなかった。依存関係をキャッシュするためのオプションは、どれも複雑そうだった。

pythonとかでCLIを作って、CIと同じことをやるようにすればいいよ。すべてのCIステージはそのサブコマンドを呼び出すだけで済む。

いや、それはダメ。Windowsの環境じゃない限り。

(1)には同意しないけど、(2)には賛成だな。リポジトリにMakefileを置いて、CIターゲットを設定するのをおすすめするよ。それで、make ci-testみたいなシンプルなコマンドでCIから簡単に呼び出せるし。Makefileは複雑にしすぎないようにね。もちろん、他のタスクランナーを使うのも全然アリだよ。

Bashは使うな 何それ？BashはCIフローに最適なスクリプト言語だよ。

以前、ビルドファームを管理するために雇われたことがあるんだ。すべてのビルドジョブは、さまざまなことをさまざまな順序で行うJenkinsプラグインの巨大なパイプラインだった。まじで悪夢だったよ。二度とやりたくない。それ以来、私が触ったすべてのCIセットアップは「make build」やそれに似たもののラッパーになっていて、すべての知恵はビルドしているコードの隣にあるGitに住んでる。これだけは譲れない。

#1のちょっとしたバリエーションだけど、bashやPowerShellで簡単にできる以上の複雑なことにはDenoのTypeScriptを使うようになったよ。pwshができることはすごく多いのは認めるけど、使い勝手が嫌いだし、慣れてない人には結構 awkward だと思う。逆に、TypeScriptやJavaScriptに近い開発者が多いと思うしね。DenoはTSを直接実行できるし、リポジトリやHTTPモジュールも別のインストールステップなしで直接参照できるから、pwsh以上のシェルスクリプトには便利だよ。例えば、DBMSクライアントを引っ張ってきて、テストや設定のために直接やり取りすることができる。だから、上記の理由から、e2eテストには他の言語よりもDenoを使うつもり。

それが私がいつもGitLab CIパイプラインでやってたことだよ。異なる目的のために専用のイメージをデプロイするだけ。一般的なTerraformコード用のTerraformイメージを用意して、バージョンの標準化が簡単になった。依存関係が多いプロジェクト用に特定のイメージも作ったから、デプロイパイプラインを数秒で実行できるようになった。でも、今はDockerイメージも維持しなきゃいけない。結局、トレードオフだよね。