pack as part of the Auto DevOps feature, to
build applications prior to deploying them.tasks
maintained by the CNB project, both of which use the lifecycle directly (i.e. they do not use pack).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 args will be appended to arguments in command, negating the new functionality (but preserving compatibility).
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).
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 e3610720d..2fe4c5cf1 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,6 +754,11 @@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]]
@@ -761,10 +766,12 @@ 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-newer-buildpack my-image
+docker run --entrypoint from-older-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.
diff --git a/docs/tools/index.html b/docs/tools/index.html
index 87fb5367c..efb217b8d 100644
--- a/docs/tools/index.html
+++ b/docs/tools/index.html
@@ -763,7 +763,7 @@ Gitlab Auto DevO
kpack
- kpack is a Kubernetes native platform maintained by VMware under the VMware Tanzu project that utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).
+ kpack is a Kubernetes native platform, belonging to the Buildpacks Community organization. It utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).
diff --git a/docs/tools/index.xml b/docs/tools/index.xml
index 72e77e9b2..3ced2d77d 100644
--- a/docs/tools/index.xml
+++ b/docs/tools/index.xml
@@ -28,7 +28,7 @@ build applications prior to deploying them.</p>
https://buildpacks.io/docs/tools/kpack/
Mon, 01 Jan 0001 00:00:00 +0000
https://buildpacks.io/docs/tools/kpack/
- <p><a href="https://github.com/pivotal/kpack">kpack</a> is a Kubernetes native platform maintained by <a href="https://www.vmware.com/company.html">VMware</a> under the <a href="https://tanzu.vmware.com/build-service">VMware Tanzu project</a> that utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).</p>
+ <p><a href="https://github.com/pivotal/kpack">kpack</a> is a Kubernetes native platform, belonging to the <a href="https://github.com/buildpacks-community">Buildpacks Community</a> organization. It utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).</p>
-
Project "Piper"
diff --git a/docs/tools/kpack/index.html b/docs/tools/kpack/index.html
index ff28d8ae8..06fb7894d 100644
--- a/docs/tools/kpack/index.html
+++ b/docs/tools/kpack/index.html
@@ -8,7 +8,7 @@
-
+
@@ -22,7 +22,7 @@
-
+
@@ -738,7 +738,7 @@
kpack
- kpack is a Kubernetes native platform maintained by VMware under the VMware Tanzu project that utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).
+ kpack is a Kubernetes native platform, belonging to the Buildpacks Community organization. It utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).
Use
To use kpack you can follow their tutorial for details on how to create a builder and use it to create application images.
An example kpack Image configuration looks like -
@@ -763,6 +763,7 @@ References
kpack GitHub repository
kpack CLI Github repository
kpack tutorial
+[kpack Donation announcement] announcement
diff --git a/index.xml b/index.xml
index 27afd1464..7feed13a6 100644
--- a/index.xml
+++ b/index.xml
@@ -593,7 +593,7 @@ build applications prior to deploying them.</p>
https://buildpacks.io/docs/tools/kpack/
Mon, 01 Jan 0001 00:00:00 +0000
https://buildpacks.io/docs/tools/kpack/
- <p><a href="https://github.com/pivotal/kpack">kpack</a> is a Kubernetes native platform maintained by <a href="https://www.vmware.com/company.html">VMware</a> under the <a href="https://tanzu.vmware.com/build-service">VMware Tanzu project</a> that utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).</p>
+ <p><a href="https://github.com/pivotal/kpack">kpack</a> is a Kubernetes native platform, belonging to the <a href="https://github.com/buildpacks-community">Buildpacks Community</a> organization. It utilizes unprivileged Kubernetes primitives to provide builds of OCI images as a platform implementation of Cloud Native Buildpacks (CNB).</p>
-
pack