Add 'container' configuration object to wrap container-specific parameters #421
Conversation
…tainer_config_object
…tainer_config_object
…tainer_config_object
…tainer_config_object
There was a problem hiding this comment.
Perhaps we should not remove the original parameters for now and instead just annotate them with @Deprecated so that we can do a patch release (aka v0.9.1) with the other small fixes, and then remove the deprecated parameters when we do a minor release (aka v0.10.0).
| @@ -69,7 +69,7 @@ public Blob getContainerConfigurationBlob() { | |||
| // Sets the entrypoint. | |||
| template.setContainerEntrypoint(image.getEntrypoint()); | |||
|
|
|||
| // Sets the entrypoint. | |||
| // Sets the main class arguments. | |||
| * A bean that configures properties of the container run from the image. This is configurable with | ||
| * Groovy closures and can be validated when used as a task input. | ||
| */ | ||
| public class ContainerConfiguration { |
There was a problem hiding this comment.
Maybe ContainerParameters so that it's not confused with the container configuration that is part of the image format?
| .setJavaArguments(jibExtension.getContainer().getArgs()) | ||
| .setJvmFlags(jibExtension.getContainer().getJvmFlags()) | ||
| .setTargetFormat(jibExtension.getContainer().getFormat()) | ||
| .setJavaArguments(jibExtension.getArgs()) |
There was a problem hiding this comment.
This could be left as jibExtension.getContainer().getArgs() since jibExtension.getArgs() (and the like) will be removed.
There was a problem hiding this comment.
I changed jibExtension.getArgs() to return container.getArgs(), and my plan was to tag jibExtension.getArgs() with @Internal instead of removing it in the future. Sort of like how getTargetImage() and getBaseImage() are handled.
jvmFlags,mainClass,args, andformatconfiguration parameters are now nested inside acontainerobject, much likeimageandcredHelperbeing nested insidetoandfrom. The original parameters are also now deprecated.Fixes #384.