-
Notifications
You must be signed in to change notification settings - Fork 40.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add bindings option for image building #23518
Comments
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 I am starting to wonder if a separate configuration file wouldn't be more suited to this. |
Any plan on this? We desperate for this feature to speed up our CI pipeline |
@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. |
@snicoll Glad to hear that, thanks! BTW, we use the newer boot maven plugin than the boot version to use the |
@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. |
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. |
spring-native need spring 2.4.4 .Does it support |
@Paradox98 this is a new feature that will be available from Spring Boot 2.5 onwards only. |
After testing, the bindings did not work: |
@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. |
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:In the Gradle plugin
bootBuildImage
configuration, the option could look like this: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. Bothhost-src
, andcontainer-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. Thenocopy
flag only applies to named volumes.[ro|rw]
mounts a volume read-only or read-write, respectively. If omitted or set torw
, 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 toshared
. For slave volumes, the mount must be set to eithershared
orslave
.The text was updated successfully, but these errors were encountered: