github actionで、docker buildを何度何度もやらないためのtips

はい、どうも

最近、github actionをごリッゴリに書いているものです

さて、今回はそんなgithub actionsで、docker buildを何度も行いたくないなーと思った時に考えたことをまとめておきます

皆さんも、github actionの中で、docker buildを何度もやることになるのが、嫌だな。。。と思いますよね？

自分の関わってるプロジェクトもコンテナでの開発になってます

なんも考えずにやると、例えばですがリントの時に、buildして、テストの時にbuildして、デプロイの時にもbuildして…とかなります

imageを何度もbuildするのは、かなり時間かかりますね

かといって、一回作ったイメージをartifactとか、chaceとかで使い回すのも、ちょっといただけません

場合によってはアリですが、結構重いimageをartifactにあげたくないというのもあると思います

はい、まあ、そういうことが起きた時というか、そういうことにならないように、考えたことをまとめておきます

まず、リントはコンテナでやらなくて良いと思ってます

例えばrubocopとかruffとか、yamllintとかですね

理由は、コンテナとローカルの環境の差異が、リンティングの結果に影響することが少ないためです

コンテナだとうまく行くけど、ローカルだと失敗するとか、リンターだとほぼないですね

なので、絶対コンテナでリントのチェックしたい！とかじゃなければ、コンテナではなくて、普通にコードをチェックアウトして、その中でリンティングしてしまえばよいです

そうすれば、buildを一回減らせます

続いて、テストです

テストは、コンテナで開発してる場合は、コンテナでテストする方が良いと思ってます

理由は、コンテナとローカルの環境の差異で落ちたりするテストがあるからです

具体的にいうとちょっとむずいですが、本番環境と同じ環境を作って、テストした方が良いと思ってます

基本はここで、初めてimageのbuildすることになるかなと思います

ここはしょうがないですね

で、ポイントなんですが、デプロイフローに行く際は、デプロイに行く前に、ECRにイメージをpushしておきます

例えば、mainブランチへのpushでlintが成功 & テストも成功の時に、ECRへイメージをpushする感じです

そうすることで、後続の処理でimageが必要になった場合は、このECRからイメージを引っ張ってくることで、buildを何度も行うことを防ぐことができます

まあ、ECRのimageのライフサイクルをちゃんと設定しておかないと、ずっとimage残るので課金されるのは注意ですね

そこが許容できるなら、ECRへのpushが良いと思います

基本、テスト以降でimageが必要になるstepがあれば、ECRのイメージをpullして、使います

artifactとかと比較しても、結構素早くイメージpullできますので、おすすめです

※こんなふうに言いましたが、体感でしかないんです。ちょっとちゃんと計測してないので、もし間違ってたら怖いな…_(:3 」∠)_

artifactとか、chaceも選択肢には上がりますが、やっぱかなり容量取りますので、その辺りはできるだけ使いたくないという人にはおすすめです

てなわけで、以下のようにすると結構buildの回数を減らせると思います！

以上ですー！