A buildpack is a unit of work that inspects your application source code and formulates a plan to build and run your application. Use this tag when using buildpacks, like if there's a failure, or if you are developing buildpacks. This can be used for both traditional buildpacks, like on Cloud Foundry or Heroku, or with Cloud Native Buildpacks.
What's a Buildpack?
A buildpack is a unit of work, typically a script or application, that runs against your application source code and produces a runnable artifact.
A buildpack goes through two main phases: detect and build. During the detect phase, the buildpack will determine if it knows how to build your application. If it does, then during the build phase, the buildpack will execute and package your application into a format that can easily be executed.
The net result is that buildpacks will take your application from its raw source code and generate a runnable artifact. Historically, the runnable artifact has been an archive file, but in the latest iteration, called Cloud Native Buildpacks, it produeces an OCI compliant image that can be run with Docker, Kubernetes or anything that supports running OCI images.
History
Buildpacks were first conceived by Heroku in 2011. Since then, they have been adopted by Cloud Foundry and other PaaS such as Google App Engine, Gitlab, Knative, Deis, Dokku, and Drie.
The Cloud Native Buildpacks project was initiated by Pivotal and Heroku in January 2018 and joined the Cloud Native Sandbox in October 2018. The project aims to unify the buildpack ecosystems with a platform-to-buildpack contract that is well-defined and that incorporates learnings from maintaining production-grade buildpacks for years at both Pivotal and Heroku.
Cloud Native Buildpacks embrace modern container standards, such as the OCI image format. They take advantage of the latest capabilities of these standards, such as cross-repository blob mounting and image layer "rebasing" on Docker API v2 registries.
