Description
Describe the bug
Setting bundling.bundlingFileAccess: BundlingFileAccess.VOLUME_COPY in AssetStaging still uses bind mounts for additional volumes created through bundling.volumes. The language in the docs does not make this explicitly clear, and leaves no good way to use additional volumes in envs where bind mounts are unavailable (e.g. DinD)
Regression Issue
- Select this option if this issue appears to be a regression.
Last Known Working CDK Version
No response
Expected Behavior
When using BundlingFileAccess.VOLUME_COPY, I expect all volumes to use the volume copy behaviour
Current Behavior
Additional volumes use bind mounts regardless of bundlingFileAccess setting
Reproduction Steps
Use AssetStaging with BundlingFileAccess.VOLUME_COPY set and an additional volume mounted
const codeAsset = new AssetStaging(this, 'CodeAsset', {
sourcePath: path.resolve('mule'),
exclude: ['target/*', 'bin/*', '*.class', '*.jar'],
bundling: {
image: DockerImage.fromRegistry('public.ecr.aws/docker/library/alpine'),
bundlingFileAccess: BundlingFileAccess.VOLUME_COPY,
volumes: [{
hostPath: '~/.m2',
containerPath: '/root/.m2',
}],
},
});Possible Solution
Rewrite the AssetStaging class to mount all volumes via the VOLUME_COPY mechanism instead of only the input and output. Alternately, extend DockerVolume as suggested in #20601 to allow each volume provided to choose its binding type (bind mount, volume copy, existing volume)
Additional Information/Context
No response
CDK CLI Version
2.174.0 (build 9604329)
Framework Version
No response
Node.js Version
v20.13.1
OS
Ubuntu
Language
TypeScript
Language Version
No response
Other information
No response