-
Notifications
You must be signed in to change notification settings - Fork 111
Expand file tree
/
Copy path_lock_buildpack.html.md.erb
More file actions
14 lines (11 loc) · 1.18 KB
/
_lock_buildpack.html.md.erb
File metadata and controls
14 lines (11 loc) · 1.18 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Every new version of <%= vars.platform_name %> ships with an updated buildpack. By default, your deployment applies
to the most recent
buildpack when you upgrade. In some cases, however, you might want to preserve an existing buildpack, rather than upgrade to the
latest version. For example, if an app you deploy depends on a specific component in Buildpack A that is not available in Buildpack B,
you might want to continue using Buildpack A.
The <code>--lock</code> flag lets you continue to use your existing buildpack even after you upgrade. Locked buildpacks are not updated when <%= vars.platform_name %> updates. You must manually unlock them to update them.
If you elect to use the <code>--unlock</code> flag, your deployment applies to the most recent buildpack when you upgrade <%=vars.platform_name%>.
```console
cf update-buildpack BUILDPACK [-p PATH] [-i POSITION] [-s STACK] [--enable|--disable] [--lock|--unlock] [--rename NEW_NAME]
```
This feature is also available through the API. See the `locked` flag under [Update a Buildpack](https://v3-apidocs.cloudfoundry.org/version/3.169.0/index.html#update-a-buildpack) in the [Cloud Foundry API](https://apidocs.cloudfoundry.org/) documentation.