2 | {{ if (or .IsNode .IsPage) }}
3 | {{ $issueBody := printf "**On Page:** [%s](%s)" .Title .Permalink | htmlEscape }}
4 | {{ $issueQuery := (querify "body" $issueBody) }}
5 | Report Issue
7 |
8 | {{ if .Params.no_edit }}
9 | {{ else }}
10 | {{ $editQuery := (querify "description" "Signed-off-by: NAME \n\n> _By signing off you acknowledge adhering to the requirements listed here: https://probot.github.io/apps/dco/_") }}
11 | Edit
13 | {{ end }}
14 | {{ end }}
15 |
16 |
--------------------------------------------------------------------------------
/themes/buildpacks/assets/scss/components/_calendar.scss:
--------------------------------------------------------------------------------
1 | // NOTE: most changes should be done via JavaScript
2 | .calendar {
3 | .fc-header-toolbar > .fc-toolbar-chunk {
4 | align-self: flex-end !important;
5 |
6 | > .fc-toolbar-title {
7 | font-size: 1.25rem;
8 | margin-bottom: 0;
9 | padding-bottom: 0;
10 | }
11 | }
12 |
13 | @media(max-width: 767px) {
14 | .fc-toolbar.fc-header-toolbar {
15 | .fc-dayGridWeek-button,.fc-dayGridMonth-button {
16 | display: none;
17 | }
18 | }
19 | }
20 |
21 | @media(max-width: 576px) {
22 | .fc-toolbar.fc-header-toolbar {
23 | display: flex;
24 | flex-direction: column;
25 | }
26 |
27 | .fc-toolbar.fc-header-toolbar .fc-left {
28 | order: 3;
29 | }
30 |
31 | .fc-toolbar.fc-header-toolbar .fc-center {
32 | order: 1;
33 | }
34 |
35 | .fc-toolbar.fc-header-toolbar .fc-right {
36 | order: 2;
37 | }
38 | }
39 | }
--------------------------------------------------------------------------------
/themes/buildpacks/layouts/shortcodes/tabs.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
18 |
19 |
20 |
24 |
25 |
--------------------------------------------------------------------------------
/content/docs/for-platform-operators/concepts/builder.md:
--------------------------------------------------------------------------------
1 | +++
2 | title="What is a builder?"
3 | weight=2
4 | aliases=[
5 | "/docs/using-pack/working-with-builders/"
6 | ]
7 | +++
8 |
9 | A `builder` is an OCI image containing
10 | an ordered combination of [buildpacks][buildpack] and
11 | a build-time base image, a [lifecycle] binary, and a reference to a runtime base image.
12 |
13 |
14 |
15 | 
16 |
17 | ## Anatomy of a builder
18 |
19 | A builder consists of the following components:
20 |
21 | * [Buildpacks][buildpack]
22 | * A [lifecycle][lifecycle]
23 | * A [build image][build-image]
24 | * A reference to a [run image][run-image]
25 |
26 | ### Resources
27 |
28 | To learn how to create your own builder, see our [Operator's Guide][operator-guide].
29 |
30 | [buildpack]: /docs/for-platform-operators/concepts/buildpack/
31 | [lifecycle]: /docs/for-platform-operators/concepts/lifecycle/
32 | [operator-guide]: /docs/for-platform-operators/
33 | [build-image]: /docs/for-platform-operators/concepts/base-images
34 | [run-image]: /docs/for-platform-operators/concepts/base-images
35 |
--------------------------------------------------------------------------------
/content/docs/reference/spec/platform-api.md:
--------------------------------------------------------------------------------
1 | +++
2 | title="Platform API"
3 | aliases=[
4 | "/docs/reference/platform-api/"
5 | ]
6 | +++
7 |
8 | The Platform specification defines the interface between the CNB [lifecycle](/docs/for-platform-operators/concepts/lifecycle/) and a [platform](/docs/for-app-developers/concepts/platform/) that runs it.
9 |
10 |
11 |
12 | ## Buildpacks
13 |
14 | Buildpacks are stored on the filesystem as unarchived files such that:
15 |
16 | * Each top-level directory is a buildpack ID.
17 | * Each second-level directory is a buildpack version.
18 |
19 | ## Users
20 |
21 | For security reasons, images built with platforms, such as `pack`, build and run as non-root users.
22 |
23 | ## Stacks (deprecated)
24 |
25 | A stack (deprecated) is the grouping together of the build and run base images, represented by a unique ID.
26 |
27 | The build image is used to run the buildpack lifecycle, and the run image is the base image for the application image.
28 |
29 | ## Further Reading
30 |
31 | You can read the complete [Platform API specification on Github](https://github.com/buildpacks/spec/blob/main/platform.md).
32 |
--------------------------------------------------------------------------------
/content/docs/for-app-developers/concepts/build.md:
--------------------------------------------------------------------------------
1 | +++
2 | title="What happens during build?"
3 | weight=3
4 | +++
5 |
6 | `Build` is the process of executing one or more [buildpacks][buildpack] against an application's source code to produce a runnable OCI image.
7 |
8 |
9 |
10 | ## Building explained
11 |
12 | 
13 |
14 | Each [buildpack] inspects the source code and provides relevant dependencies.
15 | An image is then generated from the app's source code and these dependencies.
16 |
17 | During the build process, the [build-time base image] becomes the environment in which buildpacks are executed,
18 | and the [runtime base image] becomes the base for the final app image.
19 |
20 | [Buildpacks][buildpack] can be bundled together with a specific [build-time base image], resulting in a [builder] image.
21 | Builders provide a convenient way to distribute buildpacks.
22 |
23 | [build-time base image]: /docs/for-app-developers/concepts/base-images/build/
24 | [builder]: /docs/for-platform-operators/concepts/builder
25 | [buildpack]: /docs/for-app-developers/concepts/buildpack/
26 | [runtime base image]: /docs/for-app-developers/concepts/base-images/run/
27 |
--------------------------------------------------------------------------------
/themes/buildpacks/assets/scss/_typography.scss:
--------------------------------------------------------------------------------
1 | /**********************************
2 |
3 | Typography
4 |
5 | **********************************/
6 |
7 | h1, .h1,
8 | h2, .h2,
9 | h3, .h3,
10 | h4, .h4,
11 | h5, .h5
12 | h6, .h6 {
13 | line-height: 1.2;
14 | }
15 |
16 | h2, .h2,
17 | h3, .h3,
18 | h4, .h4,
19 | h5, .h5,
20 | h6, .h6 {
21 | font-weight: 600;
22 | padding-bottom: .5rem;
23 | }
24 |
25 | h1, .h1 {
26 | font-size: 1.8rem;
27 | }
28 |
29 | h2, .h2 {
30 | font-size: 1.6rem;
31 | }
32 |
33 | h3, .h3 {
34 | font-size: 1.2rem;
35 | }
36 |
37 | h4, .h4,
38 | h5, .h5,
39 | h6, .h6 {
40 | font-size: 1.2rem;
41 | padding-bottom: .25rem;
42 | }
43 |
44 | @media (min-width: 768px) {
45 | h1, .h1 {
46 | font-size: 2.5rem;
47 | }
48 |
49 | h2, .h2 {
50 | font-size: 1.8rem;
51 | }
52 |
53 | h3, .h3 {
54 | font-size: 1.4rem;
55 | }
56 | }
57 |
58 | a {
59 | text-decoration: underline;
60 | color: inherit;
61 | transition: opacity 0.1s;
62 | }
63 |
64 | a:hover {
65 | opacity: .7;
66 | color: inherit;
67 | }
68 |
69 | b, strong {
70 | font-weight: 600;
71 | }
72 |
73 | hr {
74 | border: 0;
75 | height: 1px;
76 | background: $off-gray;
77 | }
78 |
--------------------------------------------------------------------------------
/.github/bug_report.md:
--------------------------------------------------------------------------------
1 | ### **Describe the bug**
2 | A clear and concise description of what the bug is.
3 |
4 | ### **To Reproduce**
5 | Steps to reproduce the behavior:
6 | 1. Go to '...'
7 | 2. Click on '....'
8 | 3. Scroll down to '....'
9 | 4. See error
10 |
11 | ### **Expected behavior**
12 | A clear and concise description of what you expected to happen.
13 |
14 | ### **Screenshots**
15 | If applicable, add screenshots or screen captures to help explain your problem.
16 |
17 | ### **Additional context**
18 | Add any other context about the problem here.
19 |
20 |
21 | {{ .Inner | markdownify }}
22 |
23 | 21 | 22 | 23 | **Note:** 24 | * If you want to work on an issue, you should check if it has already been assigned to anyone. **If the issue is free** and you would like to be assigned to it please comment on the issue. 25 | * If you are raising a new issue and want to work on it then also you should comment to get assigned. 26 | * Please **refrain from** adding labels to your issue/pull-request on your own. It is the job of the Project Admin and the Mentors to review your issue/pull-request and add labels accordingly. 27 | 28 | -------------------------------------------------------------------------------- /content/docs/for-buildpack-authors/tutorials/basic-buildpack/_index.md: -------------------------------------------------------------------------------- 1 | +++ 2 | title="Write a basic buildpack" 3 | weight=1 4 | +++ 5 | 6 | This is a step-by-step tutorial for creating a nodeJS Cloud Native Buildpack. 7 | 8 | 9 | 10 | ## What we'll cover 11 | 12 | - [Setting up your local environment](/docs/for-buildpack-authors/tutorials/basic-buildpack/01_setup-local-environment) 13 | - [The building blocks of a Cloud Native Buildpack](/docs/for-buildpack-authors/tutorials/basic-buildpack/02_building-blocks-cnb) 14 | - [Detecting your application](/docs/for-buildpack-authors/tutorials/basic-buildpack/03_detection) 15 | - [Building your application](/docs/for-buildpack-authors/tutorials/basic-buildpack/04_build-app) 16 | - [Making your application runnable](/docs/for-buildpack-authors/tutorials/basic-buildpack/05_make-app-runnable) 17 | - [Improving performance with caching](/docs/for-buildpack-authors/tutorials/basic-buildpack/06_caching) 18 | - [Making your buildpack configurable](/docs/for-buildpack-authors/tutorials/basic-buildpack/07_make-buildpack-configurable) 19 | 20 |
21 | 22 | 23 | Start Tutorial 24 | 25 | -------------------------------------------------------------------------------- /content/docs/for-platform-operators/how-to/integrate-ci/gitlab.md: -------------------------------------------------------------------------------- 1 | 2 | +++ 3 | title="Gitlab Auto DevOps" 4 | aliases=[ 5 | "/docs/tools/gitlab" 6 | ] 7 | weight=4 8 | +++ 9 | 10 | [Gitlab][about-gitlab] is a web-based DevOps platform. The [Auto DevOps][devops] feature uses [`pack`][pack] 11 | to build applications prior to deploying them. 12 | 13 | 14 | 15 | ## Use 16 | To use the CNB integration, you need to configure the Auto DevOps feature, as discussed in [the DevOps guide][devops-guide]. At that point, 17 | you can opt in to using Cloud Native Buildpacks by following the steps in their [CNB documentation][use-cnbs]. 18 | 19 | This may look like the following in your `.gitlab-ci.yml` file: 20 | ```yaml 21 | include: 22 | - template: Auto-DevOps.gitlab-ci.yml 23 | 24 | variables: 25 | AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED: "true" 26 | ``` 27 | 28 | ### References 29 | 30 | - [Auto Build with CNB Docs][use-cnbs] 31 | 32 | [pack]: /docs/install-pack 33 | [about-gitlab]: https://about.gitlab.com/ 34 | [devops]: https://docs.gitlab.com/ee/topics/autodevops/ 35 | [devops-guide]: https://docs.gitlab.com/ee/topics/autodevops/#get-started-with-auto-devops 36 | [use-cnbs]: https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-build-using-cloud-native-buildpacks 37 | -------------------------------------------------------------------------------- /themes/buildpacks/layouts/partials/footer.html: -------------------------------------------------------------------------------- 1 | 27 | -------------------------------------------------------------------------------- /content/docs/for-platform-operators/how-to/integrate-ci/circleci.md: -------------------------------------------------------------------------------- 1 | 2 | +++ 3 | title="CircleCI" 4 | aliases=[ 5 | "/docs/tools/circleci" 6 | ] 7 | weight=3 8 | +++ 9 | 10 | [CircleCI][circleci] is a continuous integration and delivery platform. 11 | 12 | The CNB project maintains an integration, called an [orb](https://circleci.com/orbs/), 13 | which allows users to run [pack][pack] commands inside their pipelines. 14 | 15 | 16 | 17 | ## Use 18 | To use the CNB integration, you need to declare that you are using the [`buildpacks/pack` orb](https://circleci.com/developer/orbs/orb/buildpacks/pack), and then use 19 | it in your workflow. 20 | 21 | For instance, your `.circleci/config.yml` file may look like this: 22 | ```yaml 23 | version: 2.1 24 | orbs: 25 | pack: buildpacks/pack@0.2.0 26 | workflows: 27 | main: 28 | jobs: 29 | - pack/build: 30 | image-name: sample 31 | builder: 'paketobuildpacks/builder:base' 32 | ``` 33 | 34 | For more precise steps, see the `pack-orb` [documentation][pack-orb-docs] 35 | 36 | ## References 37 | 38 | - [Source Code][pack-orb-source] 39 | - [Pack Orb Documentation][pack-orb-docs] 40 | 41 | [pack]: /docs/install-pack 42 | [circleci]: https://circleci.com/ 43 | [pack-orb-source]: https://github.com/buildpacks/pack-orb 44 | [pack-orb-docs]: https://circleci.com/developer/orbs/orb/buildpacks/pack 45 | -------------------------------------------------------------------------------- /content/docs/for-buildpack-authors/tutorials/basic-extension/_index.md: -------------------------------------------------------------------------------- 1 | +++ 2 | title="Write a basic extension" 3 | weight=2 4 | aliases = [ 5 | "/docs/extension-author-guide/create-extension" 6 | ] 7 | +++ 8 | 9 | This is a step-by-step tutorial for creating and using image extensions, which allow for customization of the build-time and runtime base images using Dockerfiles. 10 | 11 | 12 | 13 | ## What we'll cover 14 | 15 | - [Setting up your local environment](/docs/for-buildpack-authors/tutorials/basic-extension/01_setup-local-environment) 16 | - [Why this feature?](/docs/for-buildpack-authors/tutorials/basic-extension/02_why-dockerfiles) 17 | - [The building blocks of a Cloud Native Buildpacks image extension](/docs/for-buildpack-authors/tutorials/basic-extension/03_building-blocks-extension) 18 | - [Extending the build-time base image with a build.Dockerfile](/docs/for-buildpack-authors/tutorials/basic-extension/04_build-dockerfile) 19 | - [Switching the runtime base image with a run.Dockerfile](/docs/for-buildpack-authors/tutorials/basic-extension/05_run-dockerfile-switch) 20 | - [Extending the runtime base image with a run.Dockerfile](/docs/for-buildpack-authors/tutorials/basic-extension/06_run-dockerfile-extend) 21 | 22 |
23 | 24 | 25 | Start Tutorial 26 | 27 | -------------------------------------------------------------------------------- /themes/buildpacks/static/images/download-icon.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 20 | -------------------------------------------------------------------------------- /themes/buildpacks/assets/scss/components/_sidebar.scss: -------------------------------------------------------------------------------- 1 | .sidebar { 2 | font-size: 1rem; 3 | padding: 10px 0 0 0; 4 | position: -webkit-sticky; 5 | position: sticky; 6 | top: 0; 7 | 8 | ul { 9 | list-style: none; 10 | padding: 0; 11 | margin: 0; 12 | } 13 | 14 | a { 15 | text-decoration: none; 16 | color: $gray-light; 17 | display: inline-block; 18 | transition: opacity 0.2s; 19 | } 20 | 21 | .depth-0 { 22 | > a { 23 | display: block; 24 | padding: 0 20px 10px 20px; 25 | font-weight: 600; 26 | position: relative; 27 | 28 | &:before { 29 | position: absolute; 30 | content: "•"; 31 | left: 6px; 32 | opacity: 0.30; 33 | } 34 | } 35 | 36 | padding: 10px 0; 37 | border-bottom: 1px solid rgba($gray-light, 0.10); 38 | } 39 | 40 | li.parent { 41 | background: rgba($white, 0.5); 42 | } 43 | 44 | li[class*="depth-"]:not(.depth-0) { 45 | margin-left: 15px; 46 | 47 | a { 48 | padding: .25rem 1rem; 49 | } 50 | 51 | &.parent { 52 | background: 0 .75rem url("/images/list-item.svg") no-repeat; 53 | 54 | > a { 55 | color: $blue-dark; 56 | } 57 | } 58 | 59 | &.active { 60 | background: 0 .75rem url("/images/list-item-active.svg") no-repeat; 61 | 62 | > a { 63 | color: $pink; 64 | } 65 | } 66 | } 67 | } 68 | -------------------------------------------------------------------------------- /content/docs/reference/spec/buildpack-api.md: -------------------------------------------------------------------------------- 1 | +++ title="Buildpack API" 2 | aliases=[ 3 | "/docs/reference/buildpack-api/" 4 | ] 5 | +++ 6 | 7 | The Buildpack API specifies the interface between a [lifecycle] program and one or more [buildpacks][buildpack]. 8 | 9 | 10 | 11 | ## API Compatibility 12 | 13 | A [buildpack] only ever implements one Buildpack API version at a time. 14 | The implemented Buildpack API version can be found in the `buildpack.toml` file in the buildpack's root directory, 15 | or in a label on a buildpack package. 16 | 17 | A [lifecycle] may (and usually does) support more than one Buildpack API version at a time. 18 | The supported Buildpack API version(s) can be found in the `lifecycle.toml` file in a lifecycle tarball, 19 | or in a label on the [lifecycle image](https://hub.docker.com/r/buildpacksio/lifecycle). 20 | 21 | A lifecycle "supports" a buildpack if they both declare support for the same Buildpack API version in format: `
9 |
10 | {{< feature title="Advanced Caching" align="right" >}}
11 | Robust caching is used to improve performance.
12 | {{}}
13 |
14 | {{< feature title="Auto-detection" align="right" >}}
15 | Images can be built directly from application source without additional instructions.
16 | {{}}
17 |
18 | {{< feature title="Bill-of-Materials" >}}
19 | Insights into the contents of the app image through standard build-time SBOMs in CycloneDX, SPDX and Syft JSON formats.
20 | {{}}
21 |
22 | {{< feature title="Modular / Pluggable" >}}
23 | Multiple buildpacks can be used to create an app image.
24 | {{}}
25 |
26 | {{< feature title="Multi-language" >}}
27 | Supports more than one programming language family.
28 | {{}}
29 |
30 | {{< feature title="Multi-process" >}}
31 | Image can have multiple entrypoints for each operational mode.
32 | {{}}
33 |
34 | {{< feature title="Minimal app image" >}}
35 | Image contains only what is necessary.
36 | {{}}
37 |
38 | {{< feature title="Rebasing" >}}
39 | Instant updates of base images without re-building.
40 | {{}}
41 |
42 | {{< feature title="Reproducibility" >}}
43 | Reproduces the same app image digest by re-running the build.
44 | {{}}
45 |
46 | {{< feature title="Reusability" >}}
47 | Leverage production-ready buildpacks maintained by the community.
48 | {{}}
49 |
50 |
51 |
52 | ## Comparison
53 |
54 | {{< comparison-table >}}
--------------------------------------------------------------------------------
/themes/buildpacks/static/images/slack-mark.svg:
--------------------------------------------------------------------------------
1 |
2 |
3 |
31 |
--------------------------------------------------------------------------------
/content/docs/for-platform-operators/how-to/integrate-ci/kpack.md:
--------------------------------------------------------------------------------
1 |
2 | +++
3 | title="kpack"
4 | aliases=[
5 | "/docs/tools/kpack"
6 | ]
7 | weight=2
8 | +++
9 |
10 | [kpack][kpack] is a Kubernetes-native platform that uses unprivileged Kubernetes primitives to perform buildpacks builds and keep application images up-to-date.
11 |
12 | [kpack][kpack] is part of the [Buildpacks Community](https://github.com/buildpacks-community) organization.
13 |
14 |
15 |
16 | ## Use
17 | To use [kpack][kpack] you can follow their [tutorial][tutorial] for details on how to create a builder and use it to create application images.
18 | An example `kpack Image` configuration looks like -
19 |
20 | ```yaml
21 | apiVersion: kpack.io/v1alpha1
22 | kind: Image
23 | metadata:
24 | name: example-image
25 | namespace: default
26 | spec:
27 | tag:
4 |
5 |
44 |
45 |
46 | {{ end }}
47 |
--------------------------------------------------------------------------------
/content/docs/for-app-developers/how-to/build-outputs/download-sbom.md:
--------------------------------------------------------------------------------
1 |
2 | +++
3 | title="Download a Software Bill-of-Materials (SBOM)"
4 | aliases=[
5 | "/docs/features/bill-of-materials"
6 | ]
7 | summary="An SBOM can give you a layer-by-layer view of what's inside your application image."
8 | weight=3
9 | +++
10 |
11 | ## Summary
12 |
13 | A **Software-Bill-of-Materials** (`SBOM`) lists all the software components included in an image. Cloud Native Buildpacks provides all the transparency you need to have confidence in your image supply chain. Software-Bill-of-Materials in [CycloneDX](https://cyclonedx.org/), [Syft](https://github.com/anchore/syft) and [Spdx](https://spdx.dev/) formats are supported.
14 |
15 | 1. Buildpacks can populate `SBOM` information about the dependencies they have provided.
16 |
17 | ## Viewing Bill of Materials
18 |
19 | You can use the `sbom download` command to inspect your app for its Software-Bill-of-Materials. The following command will download the application layer containing the `SBOM` files to `./layers/sbom/...` on your local filesystem.
20 |
21 | ```bash
22 | pack sbom download your-image-name
23 | ```
24 |
25 | You can also choose to download the `SBOM` from an image hosted in a remote registry, as opposed to an image hosted in a Docker daemon. You use the `--remote` flag to do so.
26 |
27 | ```bash
28 | pack sbom download your-image-name --remote
29 | ```
30 |
31 | The following example demonstrates running `pack sbom download ...` on an image containing an `SBOM` in `syft` format. Running `pack sbom download ...` creates a `layers/sbom` directory and populates that directory with `sbom.syft.json` files. The combined metadata from all of the `sbom.syft.json` files is the image `SBOM`. Where an image generates CycloneDX `SBOM` metadata, the files are named `sbom.cdx.json`. Similarly, Spdx files are named `sbom.spdx.json`.
32 |
33 | ```bash
34 | layers
35 | └── sbom
36 | └── launch
37 | └── paketo-buildpacks_ca-certificates
38 | ├── helper
39 | │ └── sbom.syft.json
40 | └── sbom.syft.json
41 | ```
42 |
--------------------------------------------------------------------------------
/content/docs/for-buildpack-authors/how-to/migrate/buildpack-api-0.8-0.9.md:
--------------------------------------------------------------------------------
1 |
2 | +++
3 | title="Buildpack API 0.8 -> 0.9"
4 | aliases=[
5 | "/docs/reference/spec/migration/buildpack-api-0.8-0.9"
6 | ]
7 | weight=5
8 | +++
9 |
10 |
11 |
12 | This guide is most relevant to buildpack authors.
13 |
14 | See the [spec release](https://github.com/buildpacks/spec/releases/tag/buildpack%2Fv0.9) for Buildpack API 0.9 for the full list of changes and further details.
15 |
16 | ### Shell removal
17 |
18 | Buildpack-defined processes may no longer implicitly rely on a shell (be non-direct).
19 |
20 | In `launch.toml`, `direct` is removed as a key in the `[[processes]]` table, and all processes are inferred to be `direct = true`.
21 |
22 | Buildpack processes can still use a shell! However, the `command` must now explicitly begin with `/bin/sh` (or `cmd.exe` on Windows).
23 |
24 | ### Overridable process arguments
25 |
26 | Hand-in-hand with shell removal is the introduction of overridable process arguments.
27 |
28 | 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).
29 |
30 | For further details, see the platform [migration guide](/docs/for-platform-operators/how-to/migrate/platform-api-0.9-0.10).
31 |
32 | 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).
33 |
34 | ### Image extensions are supported (experimental)
35 |
36 | Platform 0.10 introduces image extensions as experimental components for customizing build and run-time base images (see [here](/docs/for-platform-operators/concepts/extension) for more information).
37 |
38 | For more information, see our tutorial on [authoring an image extension](/docs/for-buildpack-authors/tutorials/basic-extension).
39 |
--------------------------------------------------------------------------------
/content/docs/for-buildpack-authors/tutorials/basic-buildpack/03_detection.md:
--------------------------------------------------------------------------------
1 |
2 | +++
3 | title="Detecting your application"
4 | aliases=[
5 | "/docs/buildpack-author-guide/create-buildpack/detection"
6 | ]
7 | weight=3
8 | +++
9 |
10 |
11 |
12 | Next, you will want to actually detect that the app you are building is a node-js app. In order to do this, you will need to check for a `package.json`.
13 |
14 | Replace `exit 1` in the `detect` script with the following check:
15 |
16 | ```bash
17 | if [[ ! -f package.json ]]; then
18 | exit 100
19 | fi
20 | ```
21 |
22 | Your `node-js-buildpack/bin/detect` script should look like this:
23 |
24 |
25 | ```bash
26 | #!/usr/bin/env bash
27 | set -eo pipefail
28 |
29 | if [[ ! -f package.json ]]; then
30 | exit 100
31 | fi
32 | ```
33 |
34 | Next, rebuild your app with the updated buildpack:
35 |
36 |
37 | ```bash
38 | pack build test-node-js-app --path ./node-js-sample-app --buildpack ./node-js-buildpack
39 | ```
40 |
41 |
42 | You should see the following output:
43 |
44 | ```
45 | Previous image with name "test-node-js-app" not found
46 | ===> DETECTING
47 | examples/node-js 0.0.1
48 | ===> RESTORING
49 | ===> BUILDING
50 | ---> node-js Buildpack
51 | ERROR: failed to build: exit status 1
52 | ERROR: failed to build: executing lifecycle: failed with status code: 51
53 | ```
54 |
55 | Notice that `detect` now passes because there is a valid `package.json` in the NodeJS app at `node-js-sample-app`, but now `build` fails because it is currently written to error out.
56 |
57 | You will also notice that `RESTORING` now appears in the build output. This step is part of the buildpack lifecycle that looks to see if any previous image builds have layers that the buildpack can re-use. We will get into this topic in more detail later.
58 |
59 |
60 | ---
61 |
62 | Next Step
63 |
64 |
--------------------------------------------------------------------------------
/themes/buildpacks/layouts/_default/baseof.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | {{ partial "meta.html" . }}
6 |
7 |
9 |
10 |
11 |
13 |
16 |
17 | {{ $style := resources.Get "scss/site.scss" | toCSS }}
18 |
19 |
20 |
21 |
22 |
23 |
24 |
29 |
37 |
38 |
6 |
35 |
36 |
7 |
34 |
8 |
33 |
9 |
13 |
10 | {{ readFile "themes/buildpacks/static/images/community.svg" | safeHTML }}
11 |
12 |
15 |
32 |
16 |
31 | Join our community
17 |
18 | Slack
19 | Find us in the #buildpacks channel.
20 |
21 |
22 | Also...
23 |
30 | -
24 |
- GitHub Discussions 25 |
- BuildPacks Community on GitHub 26 |
- Mailing List 27 |
- StackOverflow 28 |
37 |
43 |
38 |
42 |
39 | {{ .Content }}
40 |
41 |
2 |
11 |
47 |
--------------------------------------------------------------------------------
/content/docs/for-buildpack-authors/how-to/migrate/buildpack-api-0.7-0.8.md:
--------------------------------------------------------------------------------
1 |
2 | +++
3 | title="Buildpack API 0.7 -> 0.8"
4 | aliases=[
5 | "/docs/reference/spec/migration/buildpack-api-0.7-0.8"
6 | ]
7 | weight=4
8 | +++
9 |
10 |
11 |
12 | This guide is most relevant to buildpack authors.
13 |
14 | See the [spec release](https://github.com/buildpacks/spec/releases/tag/buildpack%2Fv0.8) for Buildpack API 0.8 for the full list of changes and further details.
15 |
16 | ### Process-Specific Working Directory
17 |
18 | Buildpacks may specify the working directory for a process by setting the `working-dir` field on the process in [`launch.toml`](https://github.com/buildpacks/spec/blob/buildpack/0.8/buildpack.md#launchtoml-toml).
19 |
20 | Prior to this, all processes ran from the app directory (`CNB_APP_DIR`).
21 | Running a process from a different directory typically involved running a shell to execute a `cd` command and then start the process, like:
22 |
23 | ```
24 | [[processes]]
25 | command = "bash"
26 | args = ["-c", "cd
12 | {{ range $os := $.Site.Data.podman.setup }}
13 | {{ $cssClasses := "" }}
14 | {{ if $os.default }}
15 | {{ $cssClasses = "active in show" }}
16 | {{ end }}
17 |
46 |
18 |
44 | {{ end }}
45 |
19 |
29 |
43 |
30 | {{ range $method := $os.methods }}
31 | {{ $methodID := (print ($os.name | urlize) "-" (replace $method.name "." "-") | urlize) }}
32 | {{ $cssClasses := "" }}
33 | {{ if $method.default }}
34 | {{ $cssClasses = "active in show" }}
35 | {{ end }}
36 |
42 |
37 | {{ $method.install | markdownify }}
38 | {{ $method.setup | markdownify }}
39 |
40 | {{ end }}
41 |
7 |
16 |
49 |
--------------------------------------------------------------------------------
/content/docs/for-buildpack-authors/how-to/write-buildpacks/create-layer.md:
--------------------------------------------------------------------------------
1 | +++
2 | title="Create dependency layers"
3 | weight=3
4 | +++
5 |
6 | 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.
7 |
8 |
9 |
10 | That is, each directory can be used for any of the following purposes:
11 |
12 | | Layer Type | |
13 | |------------|-------------------------------------------------------------------------------------------------------------|
14 | | `Launch` | the directory will be included in the **final app image** as a single layer |
15 | | `Cache` | the directory will be included in the **build cache** and restored to the `CNB_LAYERS_DIR` on future builds |
16 | | `Build` | the directory will be accessible to **buildpacks that follow** in the build (via the environment) |
17 |
18 | A buildpack can control how a layer will be used by creating a `
17 | {{ range $os := $.Site.Data.pack.install }}
18 | {{ $cssClasses := "" }}
19 | {{ if $os.default }}
20 | {{ $cssClasses = "active in show" }}
21 | {{ end }}
22 |
48 |
23 |
46 | {{ end }}
47 |
24 |
33 |
45 |
34 | {{ range $method := $os.methods }}
35 | {{ $cssClasses := "" }}
36 | {{ if $method.default }}
37 | {{ $cssClasses = "active in show" }}
38 | {{ end }}
39 |
44 |
40 | {{ $method.content | replaceRE "" $pack_version | markdownify }}
41 |
42 | {{ end }}
43 | 
36 |
37 | The pre-populated text in the body of the issue is considered structured data, and will be used to automatically add the buildpack to the registry index. Do not change it.
38 |
39 | Click _Submit new issue_, and your request will be processed within seconds. If the image is a valid buildpack, it will be added to the registry. If there is a problem, the issue will be tagged as a "Failure" and a comment will be added with a link to get more details. Whether successful or not, the issue will be closed.
40 |
41 | > **Managing your namespace**
42 | >
43 | > The first time you publish a buildpack with a given namespace, the registry will automatically assign your GitHub user as that namespace's owner. From then on, only you can publish new buildpacks or buildpack versions under that namespace.
44 | >
45 | > If you try to publish a buildpack with a namespace that's already in use, the request will fail and the GitHub issue will be closed. You can add or change namespace owners by submitting a Pull Request to the [buildpacks/registry-namespaces](https://github.com/buildpacks/registry-namespaces/).
46 |
47 | [package]: /docs/for-buildpack-authors/how-to/distribute-buildpacks/package-buildpack
48 |
--------------------------------------------------------------------------------
/content/docs/for-platform-operators/how-to/integrate-ci/pack/_index.md:
--------------------------------------------------------------------------------
1 |
2 | +++
3 | title="Pack"
4 | aliases=[
5 | "/docs/install-pack/",
6 | "/docs/tools/pack/",
7 | "/docs/tools/pack/cli/install/"
8 | ]
9 | weight=1
10 | +++
11 |
12 | Pack is a CLI tool maintained by the CNB project to support the use of buildpacks.
13 |
14 |
15 |
16 | It enables the following functionality:
17 |
18 | 1. [`build`][build] an application using buildpacks.
19 | 1. [`rebase`][rebase] application images created using buildpacks.
20 | 1. Creation of various [components][components] used within the ecosystem.
21 |
22 | Pack works as both a [Command Line Interface (CLI)](#pack-cli) and a [Go library](#go-library).
23 |
24 | ---
25 |
26 | ## `pack` CLI
27 |
28 | ### Install
29 |
30 | You can install the most recent version of the `pack` CLI (version **{{< pack-version >}}**) on the following operating systems:
31 |
32 | {{< pack-install >}}
33 |
34 | #### RCs
35 | Prior to publishing releases, we publish RC (release candidate) builds of `pack`. You can install those by downloading the releases from the [releases page on GitHub][github-releases].
36 |
37 | #### Auto-completion
38 |
39 | `pack` supports shell completions for the following shells -
40 |
41 | * `bash`
42 | * `fish`
43 | * `zsh`
44 |
45 | To configure your `bash` shell to load completions for each session, add the following to your `.bashrc` or `.bash_profile`:
46 |
47 | ```bash
48 | . $(pack completion)
49 | ```
50 |
51 | To configure your `fish` shell to load completions for each session, add the following to your `~/.config/fish/config.fish`:
52 |
53 | ```bash
54 | source (pack completion --shell fish)
55 | ```
56 |
57 | To configure your `zsh` shell to load completions for each session, add the following to your `.zshrc`:
58 |
59 | ```bash
60 | . $(pack completion --shell zsh)
61 | ```
62 |
63 | ### References
64 |
65 | - [Docs](/docs/for-platform-operators/how-to/integrate-ci/pack/cli/pack/)
66 | - [Source](https://github.com/buildpacks/pack/)
67 |
68 | ---
69 |
70 | ## Go library
71 |
72 | ### Install
73 |
74 | ```shell
75 | go get -u github.com/buildpacks/pack
76 | ```
77 |
78 | ### References
79 |
80 | - [Docs](https://pkg.go.dev/github.com/buildpacks/pack)
81 | - [Source](https://github.com/buildpacks/pack/)
82 |
83 | [build]: /docs/for-app-developers/concepts/build/
84 | [rebase]: /docs/for-app-developers/concepts/rebase/
85 | [components]: /docs/for-platform-operators/concepts/
86 | [github-releases]: https://github.com/buildpacks/pack/releases
87 |
--------------------------------------------------------------------------------
/content/docs/for-platform-operators/how-to/build-inputs/create-builder/build-base.md:
--------------------------------------------------------------------------------
1 |
2 | +++
3 | title="Create a build base image"
4 | aliases=[
5 | "/docs/operator-guide/create-build-base"
6 | ]
7 | weight=1
8 | +++
9 |
10 | The build-time base image provides the OS-level dependencies for buildpacks at build-time.
11 |
12 |
13 |
14 | ## Define a build base image for your CNB build
15 |
16 | We need a Dockerfile similar to the following:
17 |
18 | ```Dockerfile
19 | # Define the base image
20 | FROM ubuntu:noble
21 |
22 | # Install packages that we want to make available at build time
23 | RUN apt-get update && \
24 | apt-get install -y xz-utils ca-certificates && \
25 | rm -rf /var/lib/apt/lists/*
26 |
27 | # Set required CNB user information
28 | ARG cnb_uid=1000
29 | ARG cnb_gid=1000
30 | ENV CNB_USER_ID=${cnb_uid}
31 | ENV CNB_GROUP_ID=${cnb_gid}
32 |
33 | # Create user and group
34 | RUN groupadd cnb --gid ${CNB_GROUP_ID} && \
35 | useradd --uid ${CNB_USER_ID} --gid ${CNB_GROUP_ID} -m -s /bin/bash cnb
36 |
37 | # Set user and group
38 | USER ${CNB_USER_ID}:${CNB_GROUP_ID}
39 |
40 | # Set required CNB target information
41 | LABEL io.buildpacks.base.distro.name="your distro name"
42 | LABEL io.buildpacks.base.distro.version="your distro version"
43 | ```
44 |
45 | ### Define the base image
46 |
47 | We start with `ubuntu:noble` as our base image.
48 | You can use any operating system, operating system distribution, and operating system distribution version of your choosing,
49 | as long as they are supported by the available buildpacks.
50 |
51 | ### Install packages that we want to make available at build time
52 |
53 | Install any system packages that your buildpacks will need.
54 |
55 | ### Set required CNB user information
56 |
57 | We need to define `CNB_USER_ID` and `CNB_GROUP_ID` in the environment so that the lifecycle can run as the correct user.
58 |
59 | ### Create user and group, set user and group
60 |
61 | The `USER` in the image config must match the user indicated by `CNB_USER_ID` and `CNB_GROUP_ID`.
62 |
63 | The given user **MUST NOT** be a root user, and must have a writeable home directory.
64 |
65 | ### Set required CNB target information
66 |
67 | Finally, we need to label the image with operating system distribution information for platforms and the lifecycle to use.
68 |
69 | To determine which values to provide, see [targets](/docs/for-buildpack-authors/concepts/targets/) concept information.
70 |
71 | ## Build the build base image
72 |
73 | ```bash
74 | docker build . -t cnbs/sample-base-build:noble
75 | ```
76 |
--------------------------------------------------------------------------------
/content/docs/for-platform-operators/concepts/lifecycle/extend.md:
--------------------------------------------------------------------------------
1 | +++
2 | title="Extend"
3 | weight=9
4 | +++
5 |
6 | The `extender` applies `Dockerfiles` output by image extensions to the `build` or `runtime` base image.
7 |
8 |
9 |
10 | ### Exit Codes
11 |
12 | When extending the build image:
13 |
14 | - In addition to the outputs enumerated below, outputs produced by `extender` include those produced by `builder` - as the `lifecycle` will run the `build` phase after extending the `build image`.
15 | - Platforms MUST skip the `builder` and proceed to the `exporter`.
16 |
17 | | Exit Code | Result |
18 | |-----------------|-------------------------------------|
19 | | `0` | Success |
20 | | `11` | Platform API incompatibility error |
21 | | `12` | Buildpack API incompatibility error |
22 | | `1-10`, `13-19` | Generic lifecycle errors |
23 | | `100-109` | Extension-specific lifecycle errors |
24 |
25 | - For each extension in `-
62 | {{- $expand = (or .Params.expand $isCurrent) -}}
63 | {{- $pages := (.Pages | union .Sections) }}
64 | {{- range $pages.ByWeight }}
65 | {{- if (not .Params.hidden) }}
66 | {{- template "section-tree-nav" dict "currentSection" . "currentNode" $currentNode "depth" $depth "expand" (or $expand $isParent) }}
67 | {{- end}}
68 | {{- end}}
69 |
2 |
27 |
28 |
29 | {{- define "subsection-summary" }}
30 | {{- $depth := (int .depth) }}
31 | {{- $maxDepth := (int .maxDepth) }}
32 | {{- $titleOnlyAfterDepth := .titleOnlyAfterDepth }}
33 | {{- $headerLvl := (add $depth 2) -}}
34 | {{- if (lt $depth $maxDepth) -}}
35 | {{- with .currentSection}}
36 | {{- $pages := sort (.Pages | union .Sections) "Weight" }}
37 | {{ range $pages }}
38 | {{ if (ge $depth $titleOnlyAfterDepth) }}
39 |
3 |
26 |
4 |
7 |
25 |
8 | {{ partial "support.html" . }}
9 |
10 |
24 |
11 |
13 |
14 | {{ .Content }}
15 |
16 | {{ if .Params.include_summaries }}
17 | {{- $titleOnlyAfterDepth := (int .Params.summaries_titles_only_after_depth | default 1) -}}
18 | {{- $maxDepth := (int .Params.summaries_max_depth | default 2) -}}
19 | {{- template "subsection-summary" dict "currentSection" . "depth" 0 "titleOnlyAfterDepth" $titleOnlyAfterDepth "maxDepth" $maxDepth -}}
20 | {{ end }}
21 |
22 | {{ partial "footline.html" . }}
23 | {{ .Title | markdownify }}
12 |-
40 |
41 | {{ if .Params.include_summaries }}
42 | {{- template "subsection-summary" dict "currentSection" . "depth" (add $depth 1) "titleOnlyAfterDepth" $titleOnlyAfterDepth "maxDepth" $maxDepth -}}
43 | {{ end }}
44 |
{{ .Summary | replaceRE "
54 | Learn more →
55 |
56 | {{- end }}
57 | {{ else }}
58 |
59 | Learn more →
60 |
61 | {{- end }}
62 | {{- end }}
63 | {{- end }}
64 | {{- end }}
65 | {{- end }}
66 | {{- end}}
67 |
--------------------------------------------------------------------------------
/content/docs/for-app-developers/how-to/build-outputs/inspect-app.md:
--------------------------------------------------------------------------------
1 | +++
2 | title="Inspect your application image"
3 | weight=2
4 | +++
5 |
6 | Buildpacks-built images contain metadata that allow you to audit both the image itself and the build process.
7 |
8 |
9 |
10 | Information includes:
11 |
12 | * The process types that are available and the commands associated with them
13 | * The run-image the app image was based on
14 | * The buildpacks were used to create the app image
15 | * Whether the run-image can be rebased with a new version through the `Rebasable` label or not
16 | * And more...!
17 |
18 | `pack` offers a command to help you inspect the application image and view some of its contents as shown below:
19 |
20 | ```bash
21 | pack inspect-image test-node-js-app
22 | ```
23 |
24 | You should see the following:
25 |
26 | ```text
27 | Run Images:
28 | cnbs/sample-base-run:noble
29 | ...
30 |
31 | Buildpacks:
32 | ID VERSION HOMEPAGE
33 | examples/node-js 0.0.1 -
34 |
35 | Processes:
36 | TYPE SHELL COMMAND ARGS WORK DIR
37 | web (default) bash node-js app.js /workspace
38 | ```
39 |
40 | Apart from the above standard metadata, buildpacks can also populate information about the dependencies they have provided in form of a `Software Bill-of-Materials` or [SBOM].
41 |
42 | Buildpacks-built images are constructed in a way that’s easy to understand, with each of the layers being meaningful and independent of all other layers. You can get more details about each layer and how it was created to better understand how the [build] actually worked.
43 |
44 | There are a number of available tools that can help you achieve this and understand what is contained in your `OCI` image; a popular one is [dive].
45 |
46 | `Dive` can help you inspect `OCI` images and view their layers and each layer's details. If you were to build an `OCI` image following the [multi process app] example and run `dive` on the generated image, you'll be presented with some detailed information about all of the image layers and the contents of each layer.
47 |
48 | You can use `dive` as follows:
49 |
50 | ```bash
51 | dive multi-process-app
52 | ```
53 |
54 | The output should look similar to the following:
55 |
56 | PLACEHOLDER
57 |
58 | As seen in the output above, you're presented with `Layers`, `Layer Details`, `Image Details`, and `Current Layer Contents`. To view the contents or explore the file tree of any layer, you need to select the layer on the left using the arrow keys.
59 |
60 | [SBOM]: /docs/for-app-developers/how-to/build-outputs/download-sbom
61 | [build]: https://buildpacks.io/docs/for-app-developers/concepts/build/
62 | [Dive]: https://github.com/wagoodman/dive
63 | [multi process app]: https://buildpacks.io/docs/for-app-developers/how-to/build-outputs/specify-launch-process/#build-a-multi-process-app
64 |
--------------------------------------------------------------------------------
/content/docs/for-buildpack-authors/how-to/write-buildpacks/specify-launch-processes.md:
--------------------------------------------------------------------------------
1 | +++
2 | title="Specify process types"
3 | weight=4
4 | +++
5 |
6 | One of the benefits of buildpacks is that they are multi-process - an image can have multiple entrypoints for each operational mode.
7 |
8 |
9 |
10 | A `process type` is a named process definition, contributed by a buildpack at build-time and executed by the launcher at run-time.
11 | Buildpacks declare process types during the build phase by writing entries into `