ci: Docker image ビルドキャッシュを整備

[h-takeyeah]

チケットへのリンク

• なし

やったこと

• GitHub Actions ワークフローの変更
  • 変更前: tag がこのリポジトリに push されると(=基本的にリリースの作成と同時) Docker image がビルドされ，それが GitHub Container Registry (ghcr.io) に登録されていた
  • 変更後: docker/metadata-action を使用するようにした．tag push からのビルド ghcr.io への登録，の流れは変更前と変わらないはず．今回これに加えて，(1)ビルドされる Docker image の内容，(2)ビルドキャッシュに変更が入った

(1) Docker image につけるメタデータの管理を docker/metadata-action に委譲したことでビルドされる Docker image にタグ以外に色々情報を付けられるようになった

画像は個人のリポジトリで実験したときにビルドしたイメージを docker image inspect コマンドで調べたときの様子ですが，ご覧のようにバージョンの情報などが LABEL の形でついているのが分かると思います

(2) ビルドキャッシュを保存するようにしたことで run 間¹でキャッシュを共有できるようになり，ビルド時間の短縮が見込める

実験した結果です．イメージのレイヤーをキャッシュするので Go も JavaScript も関係なく速くなりますね．

ターゲット	キャッシュなし	キャッシュあり
api	1m8s	24s
app	1m26s	21s

• キャッシュなしの run https://github.com/h-takeyeah/typing/actions/runs/14259237804
• キャッシュありの run https://github.com/h-takeyeah/typing/actions/runs/14282520080

2点注意があるので参考程度に見てください

• matrixを使っており厳密にこの PR と同じワークフローではない
• 前の run とコードにまったく変更を加えずに行った場合の結果なので理想値といえばそれまで
  • apk add のレイヤーとかは不変なはずなので，そこはいつも速くなると思う

やらないこと

• 無し

できるようになること（ユーザ目線）

• 無し

開発者目線で言えば手元に Docker image を docker pull ghcr.io/su-its/typing-server:latest として持ってきたときに，その image がどの時点のソースコードをもとにビルドされたのかを特定できるようになって嬉しい．

docker pull ghcr.io/su-its/typing-server:latest
docker image inspect --format '{{.Config.Labels}}' ghcr.io/su-its/typing-server:latest

できなくなること（ユーザ目線）

• 無し

動作確認

• フォークしたリポジトリで動作確認した．権限の問題で ghcr.io への登録だけ失敗しているがそれ以外が動いているのでよしとした．
  • https://github.com/h-takeyeah/typing/actions/runs/14372674610

その他

• docker/metadata-action では v1.0.0 というタグが来たら Docker のタグとして 1.0.0 を付けるということもできる(そういう例がネットに多かった)のですが，これまでそうしてないので互換性を考えて git のタグそのままつくようにしています
• docker/bake-action を v5 から v6 にしました．v6 では git context というのが導入されて checkout 不要になったと聞きましたが，なんか動かなかったので source: . を明示して今まで通りのやり方になるようにしています
• docker-container というドライバーを使っているのは他のドライバーが gha (GitHub Actions Cache) に Docker のビルドキャッシュを保存することに対応していないからです (setup-buildx-action のデフォルト値が docker-container ドライバーなので書かなくてもいいのですが，明示的に書いておいた方が間違いないと考えました)
• concurrency をワークフローにつけましたが同じタグを何度も同時に push することは考えにくいので効果ないかもしれないです．おまじないだと思ってつけました

Footnotes

1. GitHub の用語では1度のワークフロー実行を run という ↩

[h-takeyeah]

検討したいこと追加で，

• ターゲットの名前 api になってるの分かりづらいからディレクトリの名前に寄せて server にする？
• develop の HEAD を指してるタグってあった方がいいのだろうか？(docker/metadata-action の edge という設定を使えば可能)

[Copilot]

Copilot reviewed 4 out of 5 changed files in this pull request and generated no comments.

Files not reviewed (1)

• docker/docker-bake.hcl: Language not supported

Comments suppressed due to low confidence (4)

typing-server/docker-compose.yml:8

• Removal of the API volume mount may lead to issues if syncing local API code with the container was expected. Verify that this removal is intentional.

-    volumes:

typing-server/docker-compose.dev.yml:8

• Removal of the API volume mount in the development configuration may affect local development workflows. Confirm that this change is deliberate.

-    volumes:

.github/workflows/build-image.yml:46

• Ensure the tag pattern 'pattern={{raw}}' in the Docker metadata action is valid and produces the expected tag format.

            type=semver,pattern={{raw}}

.github/workflows/build-image.yml:56

• Verify that using the 'cwd://' prefix with the output from the Docker metadata action is supported in docker/bake-action v6 configuration.

            cwd://${{ steps.meta.outputs.bake-file-annotations }}