Add support for binding host paths or volumes into the build container used to build images with the CNB buildpacks.

In the Maven plugin image configuration, the option could look like this: 

<configuration>
    <image>
        <bindings>
            <binding>/host/path:/container/path:ro</binding>
            <binding>volume-name:/container/path:rw</binding>
        </bindings>
    </image>
</configuration>

In the Gradle plugin bootBuildImage configuration, the option could look like this: 

bootBuildImage {
    bindings = [ "/host/path:/container/path:ro", "volume-name:/container/path:rw" ]
}

Spring Boot will pass the provided strings, unvalidated and unmodified, to the Docker Container Create API when creating the builder container.

Further detail for these fields accepted by the HostConfig/Binds section of the the container config from the Docker API docs are copied below:

A list of volume bindings for this container. Each volume binding is a string in one of these forms:

  • host-src:container-dest[:options] to bind-mount a host path into the container. Both host-src, and container-dest must be an absolute path.

  • volume-name:container-dest[:options] to bind-mount a volume managed by a volume driver into the container. container-dest must be an absolute path.

options is an optional, comma-delimited list of:

  • nocopy disables automatic copying of data from the container path to the volume. The nocopy flag only applies to named volumes.

  • [ro|rw] mounts a volume read-only or read-write, respectively. If omitted or set to rw, volumes are mounted read-write.

  • [z|Z] applies SELinux labels to allow or deny multiple containers to read and write to the same volume.
    • z: a shared content label is applied to the content. This label indicates that multiple containers can share the volume content, for both reading and writing.
    • Z: a private unshared label is applied to the content. This label indicates that only the current container can use a private volume. Labeling systems such as SELinux require proper labels to be placed on volume content that is mounted into a container. Without a label, the security system can prevent a container's processes from using the content. By default, the labels set by the host operating system are not modified.
  • [[r]shared|[r]slave|[r]private] specifies mount propagation behavior. This only applies to bind-mounted volumes, not internal volumes or named volumes. Mount propagation requires the source mount point (the location where the source directory is mounted in the host operating system) to have the correct propagation properties. For shared volumes, the source mount point must be set to shared. For slave volumes, the mount must be set to either shared or slave.

Comment From: snicoll

I wonder if we aren't reaching the scope of what the Maven plugin infrastructure offers. Using nested objects like what we have done with image comes at a cost. This isn't well supported with Maven, folks expect that stuff to be exported as a command line property but we need to do something special for that to work, etc.

I am starting to wonder if a separate configuration file wouldn't be more suited to this.

Comment From: uqix

Any plan on this? We desperate for this feature to speed up our CI pipeline

Comment From: snicoll

@uqix the plan is right here on this issue. This is an enhancement scheduled for Spring Boot 2.5.x which is our next feature release.

Comment From: uqix

@snicoll Glad to hear that, thanks! BTW, we use the newer boot maven plugin than the boot version to use the build-image feature, will this bring any side effects?

Comment From: snicoll

@uqix mixing versions is not supported so you have to upgrade. If you have further questions, please ask them on StackOverflow or come chat with the community on Gitter, as mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.

Comment From: snicoll

We've been back and forth on this one and having a separate file has several downsides. It makes converging with the layer definitions super hard. Also, specifying part of this configuration in a profile makes it extra hard.

It looks like we're fighting Maven for its lack of documentation and discoverability in nested pojo structures. Now we're generating the "web site" of the maven plugin ourselves, we may be able to improve that area. As for discoverability, reaching out to IDE vendors for help could be an option.

Comment From: Paradox98

spring-native need spring 2.4.4 .Does it support

Comment From: snicoll

@Paradox98 this is a new feature that will be available from Spring Boot 2.5 onwards only.

Comment From: imhansai

After testing, the bindings did not work: bindings = listOf("upload:/upload:rw") After running the image, it was found through the inspect command that the mounts are [] How to configure bindings correctly？

Comment From: wilkinsona

@imhansai It's hard to say without more context and this isn't really the right place for that. Please follow up on Stack Overflow. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.