Hand-in-hand with shell removal is the introduction of overridable process arguments.
In launch.toml, command is now a list. The first element in command is the command, and all following entries are arguments that are always provided to the process, regardless of how the application is started. The args list now designates arguments that can be overridden by the end user - if supported by the platform (Platform API version 0.10 and above). For further details, see the platform migration guide.
For older platforms (Platform API version 0.9 and below), arguments in command will be prepended to arguments in args, negating the new functionality (but preserving compatibility).
For older platforms (Platform API version 0.9 and below), arguments in args will be appended to arguments in command, negating the new functionality (but preserving compatibility).
Platform 0.10 introduces image extensions as experimental components for customizing build and run-time base images (see here for more information).
For more information, see authoring an image extension.
diff --git a/docs/reference/spec/migration/platform-api-0.9-0.10/index.html b/docs/reference/spec/migration/platform-api-0.9-0.10/index.html index 2fe4c5cf1..e3610720d 100644 --- a/docs/reference/spec/migration/platform-api-0.9-0.10/index.html +++ b/docs/reference/spec/migration/platform-api-0.9-0.10/index.html @@ -754,11 +754,6 @@will result in the following command invocation: some-command always-1 always-2 override-1 override-2. However:
docker run --entrypoint from-newer-buildpack my-image user-1 user-2
will result in the following command invocation: some-command always-1 always-2 user-1 user-2.
For processes from newer buildpacks, upgrading the platform (without changing anything else) will change the command invocation for end-users.
-As an example, the following on Platform API version 0.9:
-docker run --entrypoint from-newer-buildpack my-image user-1 user-2
-will result in the following command invocation: some-command always-1 always-2 override-1 override-2 user-1 user-2, where overridable arguments are treated like regular arguments, and user-provided arguments are always appended. Upgrading the platform will cause override-1 and override-2 to be dropped, as shown above.
Process types contributed by older buildpacks (Buildpack API 0.8 and below) do not have overridable process arguments. Looking at metadata.toml:
[[processes]]
@@ -766,12 +761,10 @@ Older buildpacks
command = ["some-command"]
args = ["always-1", "always-2"]
The command list will never have more than one element. always-1 and always-2 are arguments that are always provided to some-command. If no user-provided arguments are specified when the application image is launched, always-1 and always-2 will be provided only. If user-provided arguments are specified, these will be appended to the args list. Example:
docker run --entrypoint from-older-buildpack my-image
+docker run --entrypoint from-newer-buildpack my-image
will result in the following command invocation: some-command always-1 always-2. However:
docker run --entrypoint from-older-buildpack my-image user-1 user-2
will result in the following command invocation: some-command always-1 always-2 user-1 user-2.
-Implications of upgrading
-For processes from older buildpacks, upgrading the platform will not change the command invocation.
Image extensions are supported (experimental)
Platform 0.10 introduces image extensions as experimental components for customizing build and run-time base images (see here for more information). Image extensions output Dockerfiles which are applied by the lifecycle using [kaniko][https://github.com/GoogleContainerTools/kaniko], a tool for building container images in Kubernetes, as a library.
Note: image extensions are not supported for Windows container images.