AssetStaging: DockerVolume uses Bind Mount with BundlingFileAccess set to VOLUME_COPY

[cgatt]

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

[pahud]

Thank you for the report. This makes sense to me. We'll review your PR when it's ready.