frontend.imageJenkinsビルドスレーブに使用するDockerイメージがあります。Jenkins Dockerプラグインは、このイメージからコンテナーをスピンアップし、コンテナー内にアーティファクトを構築します。これはすべてうまくいきます。この場合、frontend.imageAngularJsアプリの構築に使用されます。このAngularアプリの構築の一部は、アプリに必要なnpmパッケージをインストールすることです。
このプロセス、npm installには時間がかかり、3分かかるようです。npmは常にすべてのパッケージを毎回インストールします。
そこで、スレーブ用のボリュームを追加しました。これはホストマウントボリュームです。Dockerプラグインは、フロントエンドコンテナーを実行するたびにこのボリュームを使用します。
コマンドを実行するユーザーnpm installはjenkinsです。npmは、npm config get cache出力するコマンドで見つけることができるキャッシュを保持します/home/jenkins/.npm
その/slaves/volumes/tsl.frontend:/home/jenkinsため、Webコンテナのスレーブにホストボリュームをマウントしています。
Jenkinsプロジェクトを使用してAngularアプリをビルドします。問題なくビルドされ、多くのnpmパッケージがインストールされています。Dockerホストにsshしてcmd ls /slaves/volumes/tsl.frontendを実行すると、多くのnpmパッケージが表示されます。これは、スレーブのホストボリュームマウントが機能したことを意味します。

ここで、ジェンキンスプロジェクトをもう一度ビルドします。npmは、Dockerスレーブビルドコンテナがボリュームホストマウントを使用している場合でも、すべてのパッケージを再度インストールします。キャッシュされた多くのnpmパッケージを一覧表示するcmd docker exec -it <some_clever_random_container_id> bash、cmd su jenkins、cmd npm cache lsでスレーブコンテナーにバッシングすることでも確認できます。

そのため、ホストマウントボリュームにアクセス許可chmod 777があり、アクセス許可の問題がないnpm install場合でも、キャッシュを使用できません。
Dockerスレーブコンテナーを起動するJenkinsビルドで、最初に実行するcmdがnpm cache lsあり、多くのパッケージがリストされていますが、これはホストボリュームが期待どおりに機能し、npmキャッシュインデックスの整合性が壊れていないことを意味しませんか?
通常のnpm installcmd を試しました。ローカルマシンで実行すると、最初にすべてのパッケージがインストールされ、次回はほとんどパッケージがインストールされません。また、このSOの回答とcmd npm --cache-min 9999999 installから取得したnpm cache "hack"npm --skip-installed --cache-min 9999999 install
関連する質問がStackOverflowに投稿されました。
npm cache lsRAWとRAWを追加しls ~/.npm/* -alます。

