結論
COPYコマンドのファイルに変更がなくてもbuild-argで指定した内容が変われば、Dockerレイヤーキャッシュが効かない場合があります。よくよくDockerfileと睨めっこしましょう。
実行コマンド
docker build . -t app --build-arg COMMIT_HASH="hash"
ファイル
FROM node:18.17.0-bullseye
#中略
ARG COMMIT_HASH
ENV COMMIT_HASH $COMMIT_HASH
COPY ./package.json ./package.json
RUN yarn install
COPY . .
RUN yarn run build
#後略
何が起きたのか？
GitHub ActionsでDockerレイヤーキャッシュが効かず途方に暮れておりました。
しかも、直前のCOPYコマンドはCACHEDとなっており、キャッシュ設定は問題ないことと、
ファイルに変更が無いことは確認が取れておりました。
[ 8/17] COPY ./package.json xxx/package.json
CACHED
[ 9/17] RUN yarn install
[1/4] Resolving packages...
[2/4] Fetching packages...
解決方法を模索した日記
COPYがCACHEDでしたので、それより前に目がいかず、yarn install部分に何か変なところが無いか？
という観点で、調査を永遠としておりました。
ローカルで再現する方法を模索する
package.json以外を編集して再度Buildしてみますが、
案の定yarn installがキャッシュされます。
つまり、GitHub Actions固有の問題を考える。
Re-run all jobsをした場合はフルキャッシュが働く
そもそもちゃんとキャッシュが働いているのか確認するために、
GitHub Actionsの再実行Re-run all jobsを実行した時は、フルキャッシュが働くため、やはりファイルの変更が怪しいと思い始める。
関係ないファイルを編集してコミットするとyarn installがキャッシュ効かない
最初に戻りますが、READMEなど全然関係ないファイルをコミットしても、yarn installのキャッシュが効きません。
コミットが行われると、GitHub Actionsのrunnerのユーザが変更されて、コピー元の権限が変わってしまうのではないか？とか、ようやくこの段階で、コミットを気にし出します。
引数の内容が変わればキャッシュが効かなくなるという記事を見つける
調査途中で引数の内容が変わればキャッシュが効かなくなる。という内容に行きつきました。
いや、そりゃ当たり前だろ。とその時は思ってましたが自分のDockerfileを見るとCOMMIT_HASHを利用している部分がありました。
もしかしてと思い、引数を一旦コメントアウトすると、無事キャッシュが働きました。（泣きたい。
無事、もやもやが晴れてキャッシュが動き回る状況になりました。
最後に
その他、GitHub Actionsで、ブランチを変えるとキャッシュ効かないじゃん！ともがいていましたがキャッシュへアクセスできるブランチに色々と制約があります。この辺りは、公式資料をご確認ください。
宣伝
備忘録なのですが宣伝を失礼します。
弊社エンジニア募集しております！
ご興味ある方はぜひ以下より！
弊社は人、文化が良いなと個人的には感じておりますのでこちらも併せて読んでいただけますと嬉しいです。
スペースを簡単に貸し借りできるサービス「スペースマーケット」のエンジニアによる公式ブログです。 弊社採用技術スタックはこちら -> whatweuse.dev/company/spacemarket
Discussion