To write a buildpack, we follow the Buildpack Specification, which defines the contract between buildpacks and the lifecycle.
The Build Plan is a document that buildpacks can use to pass information between the detect and build phases, and between each other.
The build plan is passed (by the lifecycle) as a parameter to the detect and build binaries of each buildpack.
Each directory created by the buildpack under the CNB_LAYERS_DIR can be used as a layer in the final app image or build cache.
One of the benefits of buildpacks is that they are multi-process - an image can have multiple entrypoints for each operational mode.
Buildpacks can provide a Software Bill-of-Materials (SBOM)
to describe the dependencies that they provide.
Labels are key-value pairs, stored as strings, that are attached to an image (i.e., arbitrary metadata). Labels are used to add helpful descriptions or attributes to an application image, which are meaningful to users.
“Clearing” the buildpack environment with clear-env is the process of preventing end-users from customizing a buildpack’s behavior through environment variables.
After all buildpacks have executed, the contents of the application directory will be included in the final application image as a single layer, OR as slice layers. A slice layer contains a portion of the application directory as defined by a filepath glob.
The lifecycle provides a mechanism for buildpacks to explicitly opt into reusing any necessary dependency layers from a previous build. Buildpacks may modify cached build dependencies before reusing them.
Environment variables are a common way to configure buildpacks at build-time and the application at runtime.
The buildpacks exec.d interface allows buildpack authors to execute custom scripts or binaries when the application image is started.