mirror of https://github.com/buildpacks/docs.git
Merge branch 'main' into dependabot/go_modules/tools/github.com/cloudflare/circl-1.3.7
This commit is contained in:
Aidan Delaney
GitHub
commit
2d6c8bb5c8
|
|
@ -24,7 +24,7 @@ jobs:
|
|||
- name: Install Dependencies
|
||||
run: sudo apt-get install make curl jq
|
||||
- name: Install pack
|
||||
uses: buildpacks/github-actions/setup-pack@v5.5.1
|
||||
uses: buildpacks/github-actions/setup-pack@v5.5.4
|
||||
with:
|
||||
pack-version: '0.31.0'
|
||||
- name: Test
|
||||
|
|
@ -52,7 +52,7 @@ jobs:
|
|||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Download public folder
|
||||
uses: actions/download-artifact@v3
|
||||
uses: actions/download-artifact@v4
|
||||
with:
|
||||
name: public
|
||||
path: ./public
|
||||
|
|
|
|||
33
config.toml
33
config.toml
|
|
@ -51,15 +51,10 @@ featureKatacoda = false
|
|||
url = "https://buildpacks.devstats.cncf.io/d/8/dashboards?orgId=1&refresh=15m"
|
||||
weight = 1
|
||||
|
||||
[[menu.footer1]]
|
||||
name = "Analytics"
|
||||
url = "https://datastudio.google.com/reporting/4b23856c-6c24-44f5-86f2-333d0ad3f236"
|
||||
weight = 2
|
||||
|
||||
[[menu.footer1]]
|
||||
name = "Privacy Policy"
|
||||
url = "https://www.linuxfoundation.org/privacy/"
|
||||
weight = 3
|
||||
weight = 2
|
||||
|
||||
[[menu.footer2]]
|
||||
name = "Mailing List"
|
||||
|
|
@ -91,3 +86,29 @@ featureKatacoda = false
|
|||
[security.http]
|
||||
methods = ['(?i)GET|POST']
|
||||
urls = ['.*']
|
||||
|
||||
# For more information, see https://gohugo.io/getting-started/directory-structure/#union-file-system
|
||||
[[module.mounts]]
|
||||
source = 'content'
|
||||
target = 'content'
|
||||
[[module.mounts]]
|
||||
source = 'content/docs/.common/concepts/buildpack.md'
|
||||
target = 'content/docs/for-app-developers/concepts/buildpack.md'
|
||||
[[module.mounts]]
|
||||
source = 'content/docs/.common/concepts/buildpack.md'
|
||||
target = 'content/docs/for-buildpack-authors/concepts/buildpack.md'
|
||||
[[module.mounts]]
|
||||
source = 'content/docs/.common/concepts/buildpack.md'
|
||||
target = 'content/docs/for-platform-operators/concepts/buildpack.md'
|
||||
[[module.mounts]]
|
||||
source = 'content/docs/.common/concepts/extension.md'
|
||||
target = 'content/docs/for-buildpack-authors/concepts/extension.md'
|
||||
[[module.mounts]]
|
||||
source = 'content/docs/.common/concepts/extension.md'
|
||||
target = 'content/docs/for-platform-operators/concepts/extension.md'
|
||||
[[module.mounts]]
|
||||
source = 'content/docs/.common/concepts/composite-buildpack.md'
|
||||
target = 'content/docs/for-buildpack-authors/concepts/composite-buildpack.md'
|
||||
[[module.mounts]]
|
||||
source = 'content/docs/.common/concepts/composite-buildpack.md'
|
||||
target = 'content/docs/for-platform-operators/concepts/composite-buildpack.md'
|
||||
|
|
|
|||
|
|
@ -5,12 +5,49 @@ layout="community"
|
|||
summary="Join other users, contributors and providers of Cloud Native Buildpacks."
|
||||
+++
|
||||
|
||||
## Calendar
|
||||
# Help us build Cloud Native Buildpacks
|
||||
|
||||
Partake in one or many of our following public events:
|
||||
Cloud Native Buildpacks is better because of our contributors and maintainers. It is because of you that we can bring great software to the community. See below for further details on the several ways you can get more involved with the project.
|
||||
|
||||
## Check out GitHub
|
||||
|
||||
You can follow the work we do, be part of on-going discussions, and examine our improvement ideas on each [respective repo’s](https://github.com/buildpacks) GitHub issues page.
|
||||
|
||||
If you're a newcomer, check out the good first issue label in each repository, take [pack](https://github.com/buildpacks/pack/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) for example.
|
||||
|
||||
If you are ready to jump in and add code, tests, or help with documentation, follow the guidelines in the contributing documentation in the respective repository.
|
||||
|
||||
## Join our Slack channels
|
||||
|
||||
Join any of our several channels within the [Cloud Native Computing Foundation’s Slack workspace](https://cloud-native.slack.com/) and talk to us and over 1,000 other community members:
|
||||
|
||||
- [#buildpacks](https://cloud-native.slack.com/archives/C033DV8D9FB)
|
||||
- [#buildpacks-authors](https://cloud-native.slack.com/archives/C0333LG1E68)
|
||||
- [#buildpacks-implementation](https://cloud-native.slack.com/archives/C0331B5QS02)
|
||||
- [#buildpacks-kpack](https://cloud-native.slack.com/archives/C05GETJ2NP7)
|
||||
- [#buildpacks-learning-team](https://cloud-native.slack.com/archives/C032LNSTUNB)
|
||||
- [#buildpacks-maintainers](https://cloud-native.slack.com/archives/C0333LG7C9J)
|
||||
- [#buildpacks-mentoring](https://cloud-native.slack.com/archives/C032LNSKPP1)
|
||||
- [#buildpacks-pack-cli](https://cloud-native.slack.com/archives/C0331B61A1Y)
|
||||
- [#buildpacks-platform](https://cloud-native.slack.com/archives/C033DV9CSAD)
|
||||
- [#buildpacks-spec](https://cloud-native.slack.com/archives/C033DV9EBDF)
|
||||
|
||||
## Attend our Working Group meetings
|
||||
|
||||
Working Group Meetings are held every 1st and 3rd Thursday at 10am Pacific Time ([convert to your time zone](https://dateful.com/time-zone-converter?t=08:00&tz=PT%20%28Pacific%20Time%29)) and every 2nd and 4th Thursday at 7am Pacific Time ([convert to your time zone](https://dateful.com/time-zone-converter?t=08:00&tz=PT%20%28Pacific%20Time%29)).
|
||||
|
||||
{{< calendar >}}
|
||||
|
||||
Attend working group meetings to hear the latest development updates, provide feedback, ask questions, meet the maintainers, and get to know other members of the community.
|
||||
|
||||
Join our [Mailing List](https://lists.cncf.io/g/cncf-buildpacks) to get updates on the project and invitations to working group meetings.
|
||||
|
||||
- [Meeting Zoom Link](https://zoom.us/j/91289548697?pwd=SzNzaHdmVUVBZGhJM20weThIdGdkUT09)
|
||||
- See previous community meetings on our [YouTube Playlist](https://www.youtube.com/playlist?list=PL1p8pquzNvRpDbbgZ0db0MRA-W5_w0G1U)
|
||||
- [Meeting agenda](https://docs.google.com/document/d/18gkdfJsy8AQWsOgzPbLRnxN4a-WtUoaCM2Lh7-08rdo/edit#heading=h.3kg2wwvbnkb3)
|
||||
|
||||
Topics should be added to the agenda in the public [Google Doc](https://docs.google.com/document/d/18gkdfJsy8AQWsOgzPbLRnxN4a-WtUoaCM2Lh7-08rdo/edit#heading=h.3kg2wwvbnkb3) the day prior to the meeting. The list of topics will be finalized by the meeting organizers. If any scheduled topics are covered in less than the allotted time, additional topics may be covered.
|
||||
|
||||
## Contributing
|
||||
|
||||
#### How can I start contributing?
|
||||
|
|
@ -136,3 +173,13 @@ The full text of the certification is available [here](https://developercertific
|
|||
|
||||
- Push to GitHub: `git push origin {{BRANCH_NAME}}`
|
||||
- [Create the pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork).
|
||||
|
||||
## Donate your project to Buildpacks Community, our vendor-neutral GitHub organization
|
||||
|
||||
As our adopters and contributors have grown substantially over the last several years, we created a new GitHub organization to allow us to foster partner projects. The [Buildpacks Community organization](https://github.com/buildpacks-community/) is a vendor-neutral Github organization where the community provides trusted Cloud Native Buildpacks tooling, platforms, and integrations.
|
||||
|
||||
For a project to be admitted to the Buildpacks community organization, it must meet several criteria, but the first step is to create a Github issue in the Buildpacks Community repository. Once it is mature enough to be part of the core Buildpacks organization, the project maintainers can request for the project to be graduated into the core Buildpacks organization. Kpack was the first project to be donated into this new org and you can read more about the first major community project donation [here](https://medium.com/buildpacks/kpack-joins-the-buildpacks-community-organization-223e59bda951).
|
||||
|
||||
If you want to know more and how you can donate your own project, you can find all the details in the [RFC](https://github.com/buildpacks/rfcs/blob/main/text/0117-buildpacks-community.md).
|
||||
|
||||
##### Thank you for your interest in making this project even better.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,54 @@
|
|||
+++
|
||||
title="What is a buildpack?"
|
||||
weight=1
|
||||
+++
|
||||
|
||||
A `buildpack` is software that transforms application source code into runnable artifacts
|
||||
by analyzing the code and determining the best way to build it.
|
||||
|
||||
<!--more-->
|
||||
|
||||
|
||||
|
||||
## Why buildpacks?
|
||||
|
||||
Buildpacks allow application developers to focus on what they do best - writing code, without having to worry about image security, optimizing container images, or container build strategy.
|
||||
|
||||
How much time have you spent struggling to wrangle yet another Dockerfile? Copying and pasting random Dockerfile snippets into every project? Buildpacks can help! They are a better approach to building container images for applications.
|
||||
|
||||
## What do they look like?
|
||||
|
||||
Typical buildpacks consist of at least three files:
|
||||
|
||||
* `buildpack.toml` -- provides metadata about the buildpack, containing information such as its name, ID, and version.
|
||||
* `bin/detect` -- performs [detect](#detect).
|
||||
* `bin/build` -- performs [build](#build).
|
||||
|
||||
## How do they work?
|
||||
|
||||
|
||||
|
||||
**Each buildpack has two jobs to do**
|
||||
|
||||
### Detect
|
||||
|
||||
The buildpack determines if it is needed or not.
|
||||
|
||||
For example:
|
||||
|
||||
- A Python buildpack may look for a `requirements.txt` or a `setup.py` file.
|
||||
- A Node buildpack may look for a `package-lock.json` file.
|
||||
|
||||
### Build
|
||||
|
||||
The buildpack transforms application source code in some way, for example by
|
||||
|
||||
- Setting build-time and run-time environment variables.
|
||||
- Downloading dependencies.
|
||||
- Running source code compilation (if needed).
|
||||
- Configuring the application entrypoint and any startup scripts.
|
||||
|
||||
For example:
|
||||
|
||||
- A Python buildpack may run `pip install -r requirements.txt` if it detected a `requirements.txt` file.
|
||||
- A Node buildpack may run `npm install` if it detected a `package-lock.json` file.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
+++
|
||||
title="What is a composite buildpack?"
|
||||
weight=99
|
||||
+++
|
||||
|
||||
A composite buildpack, also sometimes called a "meta-buildpack",
|
||||
is a buildpack that does not contain any `./bin/detect` or `./bin/build` binaries,
|
||||
but instead references other buildpacks in its `buildpack.toml` via the `[[order]]` array.
|
||||
|
||||
This is useful for composing more complex detection strategies.
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
|
||||
+++
|
||||
title="What is an image extension?"
|
||||
aliases=[
|
||||
"/docs/features/dockerfiles"
|
||||
]
|
||||
weight=99
|
||||
+++
|
||||
|
||||
An `image extension` is software that generates Dockerfiles that can be used to extend base images for buildpacks builds.
|
||||
|
||||
<!--more-->
|
||||
|
||||
## Why image extensions?
|
||||
|
||||
Buildpacks can do a lot, but there are some things buildpacks can't do. They can't install operating system packages,
|
||||
for example. Why not?
|
||||
|
||||
Buildpacks do not run as the `root` user and cannot make arbitrary changes to the filesystem. This enhances security,
|
||||
enables buildpack interoperability, and preserves the ability to rebase - but it comes at a cost. Base image authors
|
||||
must anticipate the OS-level dependencies that will be needed at build and run-time ahead of time, and this isn't always
|
||||
possible.
|
||||
|
||||
This has been a longstanding source of [discussion](https://github.com/buildpacks/rfcs/pull/173) within the CNB project:
|
||||
how can we preserve the benefits of buildpacks while enabling more powerful capabilities?
|
||||
|
||||
### Buildpacks and Dockerfiles can work together
|
||||
|
||||
Buildpacks are often presented as an alternative to Dockerfiles, but we think buildpacks and Dockerfiles can work
|
||||
together.
|
||||
|
||||
Buildpacks are optimized for creating layers that are efficient and logically mapped to the dependencies that they
|
||||
provide. By contrast, Dockerfiles are the most-used and best-understood mechanism for constructing base images and
|
||||
installing OS-level dependencies for containers.
|
||||
|
||||
The CNB Dockerfiles feature allows Dockerfiles to "provide" dependencies that buildpacks "require" through a
|
||||
shared [build plan], by introducing the concept of image extensions.
|
||||
|
||||
## What do they look like?
|
||||
|
||||
Image extensions are buildpack-like components that use a restricted `Dockerfile` syntax to expand base images. Their
|
||||
purpose is to generate Dockerfiles that can be used to extend the builder or run images prior to buildpacks builds.
|
||||
|
||||
An image extension could be defined with the following directory:
|
||||
|
||||
```
|
||||
.
|
||||
├── extension.toml <- similar to a buildpack buildpack.toml
|
||||
├── bin
|
||||
│ ├── detect <- similar to a buildpack ./bin/detect
|
||||
│ ├── generate <- similar to a buildpack ./bin/build
|
||||
```
|
||||
|
||||
* The `extension.toml` provides metadata about the extension, containing information such as its name, ID, and version.
|
||||
* `./bin/detect` performs [detect](#detect). It analyzes application source code to determine if the extension
|
||||
is needed and contributes build plan entries.
|
||||
* `./bin/generate` performs [generate](#generate) (a new lifecycle phase that happens after `detect`). It
|
||||
outputs either or both of `build.Dockerfile` or `run.Dockerfile` for extending the builder or run image.
|
||||
|
||||
## How do they work?
|
||||
|
||||
**Each image extension has two jobs to do**
|
||||
|
||||
### Detect
|
||||
|
||||
The extension determines if it is needed or not.
|
||||
|
||||
Like buildpacks, extensions participate in the `detect` phase - analyzing application source code to determine if they
|
||||
are needed. During `detect`, extensions can contribute to
|
||||
the [build plan] - recording dependencies that they are able to "
|
||||
provide" (though unlike buildpacks, they can't "require" anything).
|
||||
|
||||
If the provided order contains extensions, the output of `detect` will be a group of image extensions and a group of
|
||||
buildpacks that together produce a valid build plan. Image extensions only generate Dockerfiles - they don't create
|
||||
layers or participate in the `build` phase.
|
||||
|
||||
### Generate
|
||||
|
||||
The extension outputs Dockerfiles that can be used to extend either or both of the build-time base image and the runtime base image.
|
||||
|
||||
For more information and to see a build in action,
|
||||
see [authoring an image extension](/docs/for-buildpack-authors/tutorials/basic-extension).
|
||||
|
||||
[build plan]: /docs/for-buildpack-authors/how-to/write-buildpacks/use-build-plan
|
||||
|
|
@ -8,12 +8,13 @@ getting-started=true
|
|||
|
||||
In this tutorial, we'll explain how to use `pack` and **buildpacks** to create a runnable app image from source code.
|
||||
|
||||
In order to run the build process in an isolated fashion, `pack` uses **Docker**. That means you'll need to make sure you have both `docker` and `pack` installed:
|
||||
|
||||
{{< download-button href="https://store.docker.com/search?type=edition&offering=community" color="blue" >}} Install Docker {{</>}}
|
||||
In order to run the build process in an isolated fashion, `pack` uses **Docker** or a Docker-compatible daemon to create the containers where buildpacks execute.
|
||||
That means you'll need to make sure you have both `pack` and a daemon installed:
|
||||
|
||||
{{< download-button href="/docs/install-pack" color="pink" >}} Install pack {{</>}}
|
||||
|
||||
{{< download-button href="https://store.docker.com/search?type=edition&offering=community" color="blue" >}} Install Docker {{</>}} or alternatively, see [this page](/docs/for-app-developers/how-to/special-cases/build-on-podman) about working with `podman`.
|
||||
|
||||
> **NOTE:** `pack` is only one implementation of the [Cloud Native Buildpacks Platform Specification][cnb-platform-spec]. Additionally, not all Cloud Native Buildpacks Platforms require Docker.
|
||||
|
||||
[cnb-platform-spec]: https://github.com/buildpacks/spec/blob/main/platform.md
|
||||
|
|
|
|||
|
|
@ -1,30 +0,0 @@
|
|||
<svg xmlns="http://www.w3.org/2000/svg" width="300" height="300" viewBox="0 0 300 300">
|
||||
<defs>
|
||||
<linearGradient id="a" x1="50%" x2="50%" y1="0%" y2="100%">
|
||||
<stop offset="0%" stop-color="#F12FA5"/>
|
||||
<stop offset="100%" stop-color="#DE156C"/>
|
||||
</linearGradient>
|
||||
<linearGradient id="b" x1="50%" x2="50%" y1="0%" y2="100%">
|
||||
<stop offset="0%" stop-color="#7E8BCC"/>
|
||||
<stop offset="100%" stop-color="#47529D"/>
|
||||
</linearGradient>
|
||||
<linearGradient id="c" x1="50%" x2="50%" y1="0%" y2="100%">
|
||||
<stop offset="0%" stop-color="#4B5399"/>
|
||||
<stop offset="100%" stop-color="#252960"/>
|
||||
</linearGradient>
|
||||
</defs>
|
||||
<g fill="none" fill-rule="evenodd" transform="translate(88 98)">
|
||||
<g transform="translate(64 54)">
|
||||
<path fill="#DE156C" d="M27.9980217,14.1759296 L6.00104499,1.4671193 C4.08820782,0.361972668 1.64164856,1.01673522 0.536501922,2.92957239 C0.185040439,3.53789762 8.02140138e-16,4.2280615 8.8817842e-16,4.93061738 L6.21724894e-15,30.3575366 C6.39219706e-15,31.7860964 0.761864077,33.1062197 1.99878189,33.8209347 L27.9978486,48.8436962 C29.2360361,49.5591448 30.7619766,49.5591668 32.0001848,48.843754 L58.0011181,33.8209155 C59.2380923,33.1062156 60,31.7860607 60,30.3574596 L60,4.93038624 C60,2.72124724 58.209139,0.93038624 56,0.93038624 C55.2974833,0.93038624 54.6073565,1.11540606 53.999055,1.46683038 L32.0000116,14.1759874 C30.7618914,14.8912669 29.2361213,14.8912449 27.9980217,14.1759296 Z"/>
|
||||
<path fill="url(#a)" d="M30,17.6406351 L30,43.0690981 C30,45.2782371 31.790861,47.0690981 34,47.0690981 C34.7026041,47.0690981 35.3928136,46.8840323 36.0011681,46.5325251 L58.0011681,33.8209251 C59.2381141,33.1062177 60,31.7860786 60,30.3574981 L60,4.93050181 C60,2.72136281 58.209139,0.930501806 56,0.930501806 C55.2974637,0.930501806 54.6073184,1.11553193 53.999005,1.46697483 L31.999005,14.1771082 C30.7619614,14.8917895 30,16.2119833 30,17.6406351 Z"/>
|
||||
</g>
|
||||
<g transform="translate(32)">
|
||||
<path fill="#47529D" d="M53.9987319,3.4677639 L32.0031347,16.1776673 C30.7649575,16.8931338 29.239017,16.8931778 28.0007985,16.1777829 L6.00106808,3.46718599 C4.08823828,2.36202661 1.64167464,3.01677285 0.53651526,4.92960265 C0.185045199,5.53793338 -1.28621931e-15,6.22810581 -8.8817842e-16,6.93067073 L-3.55271368e-15,32.3592879 C-3.37774923e-15,33.787981 0.762005094,35.1082064 1.99910503,35.8228726 L28.0009716,50.8440163 C29.2391022,51.5592779 30.7648723,51.5592338 32.0029616,50.8439007 L58.001095,35.822911 C59.2380822,35.1082147 60,33.7880525 60,32.3594419 L60,6.93113306 C60,4.72199406 58.209139,2.93113306 56,2.93113306 C55.2973567,2.93113306 54.6071101,3.11621951 53.9987319,3.4677639 Z"/>
|
||||
<path fill="url(#b)" d="M53.9988319,3.46747492 L31.9988319,16.1790749 C30.7618859,16.8937823 30,18.2139214 30,19.6425019 L30,45.0694982 C30,47.2786372 31.790861,49.0694982 34,49.0694982 C34.7025363,49.0694982 35.3926816,48.8844681 36.000995,48.5330252 L58.000995,35.8228918 C59.2380386,35.1082105 60,33.7880167 60,32.3593649 L60,6.93090188 C60,4.72176288 58.209139,2.93090188 56,2.93090188 C55.2973959,2.93090188 54.6071864,3.1159677 53.9988319,3.46747492 Z"/>
|
||||
</g>
|
||||
<g transform="translate(0 52)">
|
||||
<path fill="#252960" d="M27.999005,16.1759585 L6.00099498,3.46697483 C4.08814186,2.36185582 1.64159204,3.0166537 0.536473029,4.92950682 C0.185030128,5.53782018 8.02142537e-16,6.22796551 8.8817842e-16,6.93050181 L-1.77635684e-15,32.3574981 C9.3626245e-16,33.7860786 0.761885902,35.1062177 1.99883191,35.8209251 L27.9988319,50.8437251 C29.2370298,51.5591558 30.7629702,51.5591558 32.0011681,50.8437251 L58.0011681,35.8209251 C59.2381141,35.1062177 60,33.7860786 60,32.3574981 L60,6.93050181 C60,4.72136281 58.209139,2.93050181 56,2.93050181 C55.2974637,2.93050181 54.6073184,3.11553193 53.999005,3.46697483 L32.000995,16.1759585 C30.7628851,16.8912559 29.2371149,16.8912559 27.999005,16.1759585 Z"/>
|
||||
<path fill="url(#c)" d="M30,19.6406351 L30,45.0690981 C30,47.2782371 31.790861,49.0690981 34,49.0690981 C34.7026041,49.0690981 35.3928136,48.8840323 36.0011681,48.5325251 L58.0011681,35.8209251 C59.2381141,35.1062177 60,33.7860786 60,32.3574981 L60,6.93050181 C60,4.72136281 58.209139,2.93050181 56,2.93050181 C55.2974637,2.93050181 54.6073184,3.11553193 53.999005,3.46697483 L31.999005,16.1771082 C30.7619614,16.8917895 30,18.2119833 30,19.6406351 Z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 4.3 KiB |
|
|
@ -11,36 +11,46 @@ The **run image** provides the base image for application images.
|
|||
|
||||
<!--more-->
|
||||
|
||||
The lifecycle requires a reference to a run image and (where necessary) possible run image mirrors in order to construct the application image.
|
||||
CNB tooling requires a reference to a run image and (where necessary) run image mirrors in order to construct the application image.
|
||||
|
||||
### Run image mirrors
|
||||
|
||||
Run image mirrors provide alternate locations for run images, for use during `build` or `rebase`.
|
||||
When running `build` with a builder containing run image mirrors, `pack` will select a run image
|
||||
whose registry location matches that of the specified app image (if no registry host is specified in the image name,
|
||||
DockerHub is assumed). This is useful when publishing the resulting app image (via the `--publish` flag or via
|
||||
`docker push`), as the app's base image (i.e. run image) will be located on the same registry as the app image itself,
|
||||
reducing the amount of data transfer required to push the app image.
|
||||
Run image mirrors provide alternate locations for `run images`, for use during `build` or `rebase`.
|
||||
|
||||
In the following example, assuming a builder configured with the example TOML above, the selected run image will be
|
||||
`registry.example.com/example/run`.
|
||||
When run image mirrors are defined, CNB tooling will try to find a run image that resides on the same registry as the application image,
|
||||
based on the image name provided.
|
||||
|
||||
This is to reduce the amount of data transfer required to push the application image to a registry.
|
||||
|
||||
#### Example - determining the registry
|
||||
|
||||
If the application image name is:
|
||||
|
||||
* `registry.example.com/example/app` - the registry is `registry.example.com`
|
||||
* `example/app` (registry omitted) - Docker Hub is assumed; the registry is `index.docker.io`
|
||||
|
||||
#### Example - determining the run image mirror
|
||||
|
||||
If your builder has a run image with mirrors defined as follows (see [how to create a builder](/docs/for-platform-operators/how-to/build-inputs/create-builder/builder) for more information):
|
||||
|
||||
```toml
|
||||
[[run.images]]
|
||||
image = "example/run"
|
||||
mirrors = ["registry.example.com/example/run"]
|
||||
```
|
||||
|
||||
Then if you run `pack build` as follows:
|
||||
|
||||
```bash
|
||||
$ pack build registry.example.com/example/app
|
||||
```
|
||||
|
||||
while naming the app without a registry specified, `example/app`, will cause `example/run` to be selected as the app's
|
||||
run image.
|
||||
the selected run image will be `registry.example.com/example/run`.
|
||||
|
||||
```bash
|
||||
$ pack build example/app
|
||||
```
|
||||
|
||||
> For local development, it's often helpful to override the run image mirrors in a builder. For this, the
|
||||
> `pack config run-image-mirrors` command can be used. This command does not modify the builder, and instead configures the
|
||||
> local environment.
|
||||
> For local development, it's often helpful to override the run image mirrors in a builder.
|
||||
> For this, the `pack config run-image-mirrors` command can be used.
|
||||
> This command does not modify the builder, and instead configures the local environment.
|
||||
>
|
||||
> To see what run images are configured for a builder, the
|
||||
> `builder inspect` command can be used. `builder inspect` will output built-in and locally-configured run images for
|
||||
> a given builder, along with other useful information. The order of the run images in the output denotes the order in
|
||||
> which they will be matched during `build`.
|
||||
> To see what run images are configured for a builder, `pack builder inspect` can be used.
|
||||
> `pack builder inspect` will output built-in and locally-configured run images for a given builder, along with other useful information.
|
||||
> The order of the run images in the output denotes the order in which they will be matched during `build`.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ weight=3
|
|||
|
||||
## Building explained
|
||||
|
||||
|
||||
|
||||
|
||||
Each [buildpack] inspects the source code and provides relevant dependencies.
|
||||
An image is then generated from the app's source code and these dependencies.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ The [build-time base image] provides the base environment for the `builder`
|
|||
(e.g., an Ubuntu Jammy OS image with build tooling) and
|
||||
a [runtime base image] provides the base environment for the `app image` during runtime.
|
||||
|
||||
|
||||
|
||||
|
||||
Under the hood a builder uses the [lifecycle] to run the `detect` phase for all the `buildpacks` it contains, in order,
|
||||
and then proceeds to run the `build` phase for all the `buildpacks` that passed detection.
|
||||
|
|
|
|||
|
|
@ -1,39 +0,0 @@
|
|||
+++
|
||||
title="What is a buildpack?"
|
||||
weight=1
|
||||
+++
|
||||
|
||||
A `buildpack` is software that examines your source code and determines the best way to build it.
|
||||
|
||||
<!--more-->
|
||||
|
||||
|
||||
|
||||
## How do they work?
|
||||
|
||||
|
||||
|
||||
**Each buildpack has two phases**
|
||||
|
||||
### Detect phase
|
||||
|
||||
The `detect` phase runs against your source code to determine if the buildpack is applicable or not.
|
||||
Once a buildpack is `detected` to be applicable, it proceeds to the `build` stage. If the project fails `detection` the `build` stage for a specific buildpack is skipped.
|
||||
|
||||
For example:
|
||||
|
||||
- A Python buildpack may look for a `requirements.txt` or a `setup.py` file pass
|
||||
- A Node buildpack may look for a `package-lock.json` file to pass
|
||||
|
||||
### Build phase
|
||||
|
||||
The `build` phase runs against your source code to -
|
||||
|
||||
- Set up the build-time and run-time environment
|
||||
- Download dependencies and compile your source code (if needed)
|
||||
- Set appropriate entry point and startup scripts
|
||||
|
||||
For example:
|
||||
|
||||
- A Python buildpack may run `pip install -r requirements.txt` if it detected a `requirements.txt` file
|
||||
- A Node buildpack may run `npm install` if it detected a `package-lock.json` file
|
||||
|
|
@ -16,7 +16,7 @@ weight=4
|
|||
|
||||
By using image layer rebasing, this command avoids the need to fully rebuild the app.
|
||||
|
||||
|
||||
|
||||
|
||||
At its core, image rebasing is a simple process. By inspecting an app image, `rebase` can determine whether or not a
|
||||
newer version of the app's base image exists (either locally or in a registry).
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
+++
|
||||
title="How To"
|
||||
weight=3
|
||||
|
||||
include_summaries=true
|
||||
+++
|
||||
|
|
|
|||
|
|
@ -0,0 +1,30 @@
|
|||
+++
|
||||
title="Specify export target"
|
||||
weight=50
|
||||
+++
|
||||
|
||||
Tell `pack` where you want your application image to be saved.
|
||||
|
||||
<!--more-->
|
||||
|
||||
By default, when you build an application with `pack build <my-image>`, the image will be saved to a daemon, such as Docker or [Podman][podman],
|
||||
and you can view the image using a command such as `docker image ls`.
|
||||
|
||||
However, you could also choose to "publish" the application to an OCI registry, such as Docker Hub or Google Artifact Registry,
|
||||
or even to a local registry, by providing the `pack build --publish` flag.
|
||||
|
||||
Or, you could save the image in OCI layout format on disk by prefixing your image name with `oci:`, as in `pack build oci:<my-image>`.
|
||||
See [here][OCI layout] for more information about working with layout images.
|
||||
|
||||
## FAQ: What am I using the daemon for?
|
||||
|
||||
Buildpacks always need to run in a containerized environment.
|
||||
Therefore, even when you publish the application image to a registry,
|
||||
`pack` is still using a daemon under the hood to create the build container(s) where buildpacks run.
|
||||
|
||||
The relationship between the build container and the application container can be seen in the diagram below:
|
||||
|
||||
|
||||
|
||||
[podman]: /docs/for-app-developers/how-to/special-cases/build-on-podman
|
||||
[OCI layout]: /docs/for-app-developers/how-to/special-cases/export-to-oci-layout
|
||||
|
|
@ -1,6 +1,5 @@
|
|||
+++
|
||||
title="Build in custom environments"
|
||||
weight=3
|
||||
|
||||
include_summaries=true
|
||||
+++
|
||||
|
|
|
|||
|
|
@ -7,6 +7,11 @@ aliases=[
|
|||
weight=2
|
||||
+++
|
||||
|
||||
You can use buildpacks to build container images that run Windows containers on Windows (WCOW).
|
||||
|
||||
This page is not relevant if your host machine is Windows but you are running Linux containers on Windows (LCOW);
|
||||
in this case, no special configuration is required.
|
||||
|
||||
<!--more-->
|
||||
|
||||
> **EXPERIMENTAL** Windows support is experimental!
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ aliases=[
|
|||
"/docs/features/experimental/export-to-oci-layout"
|
||||
]
|
||||
weight=3
|
||||
summary="The OCI Image Layout is the directory structure for OCI content-addressable blobs and location-addressable references."
|
||||
+++
|
||||
|
||||
<!--more-->
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
+++
|
||||
title="Concepts"
|
||||
weight=2
|
||||
|
||||
include_summaries=true
|
||||
+++
|
||||
|
|
|
|||
|
|
@ -57,4 +57,4 @@ The [Operator's Guide][operator-guide] has more information on creating builders
|
|||
[order-resolution]: https://github.com/buildpacks/spec/blob/main/buildpack.md#order-resolution
|
||||
[operator-guide]: /docs/for-platform-operators/
|
||||
[builder]: /docs/for-platform-operators/concepts/builder/
|
||||
[meta-buildpack]: /docs/for-platform-operators/concepts/buildpack/#meta-buildpack
|
||||
[meta-buildpack]: /docs/for-platform-operators/concepts/composite-buildpack
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
../../for-app-developers/concepts/buildpack.md
|
||||
|
|
@ -14,7 +14,7 @@ There are three types of layers that can be contributed to an image
|
|||
|
||||
* `build` layers -- the directory will be accessible by subsequent buildpacks,
|
||||
* `cache` layers -- the directory will be included in the cache,
|
||||
* `launch` layers -- the directory will be included in the run image as a single layer,
|
||||
* `launch` layers -- the directory will be included in the final app image as a single layer,
|
||||
|
||||
In this section we look at caching each layer type.
|
||||
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
../../for-platform-operators/concepts/dockerfiles.md
|
||||
|
|
@ -1,6 +1,5 @@
|
|||
+++
|
||||
title="How To"
|
||||
weight=3
|
||||
|
||||
include_summaries=true
|
||||
+++
|
||||
|
|
|
|||
|
|
@ -0,0 +1,10 @@
|
|||
+++
|
||||
title="Craft a buildpack order"
|
||||
weight=99
|
||||
+++
|
||||
|
||||
<!--more-->
|
||||
|
||||
This page is a stub! The CNB project is applying to [Google Season of Docs](https://developers.google.com/season-of-docs/docs/timeline) to receive support for improving our documentation. Please check back soon.
|
||||
|
||||
If you are familiar with this content and would like to make a contribution, please feel free to open a PR :)
|
||||
|
|
@ -4,7 +4,7 @@ title="Package a buildpack or extension"
|
|||
aliases=[
|
||||
"/docs/buildpack-author-guide/package-a-buildpack"
|
||||
]
|
||||
weight=5
|
||||
weight=4
|
||||
summary="Learn how to package your buildpack or extension for distribution."
|
||||
+++
|
||||
|
||||
|
|
|
|||
|
|
@ -33,6 +33,6 @@ For older platforms (Platform API version 0.9 and below), arguments in `command`
|
|||
|
||||
### Image extensions are supported (experimental)
|
||||
|
||||
Platform 0.10 introduces image extensions as experimental components for customizing build and run-time base images (see [here](/docs/for-platform-operators/concepts/dockerfiles) for more information).
|
||||
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).
|
||||
|
||||
For more information, see our tutorial on [authoring an image extension](/docs/for-buildpack-authors/tutorials/basic-extension).
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
+++
|
||||
title="Provide a Software Bill-of-Materials"
|
||||
weight=2
|
||||
weight=5
|
||||
+++
|
||||
|
||||
Buildpacks can provide a [Software `Bill-of-Materials`](https://en.wikipedia.org/wiki/Software_bill_of_materials) (SBOM)
|
||||
|
|
|
|||
|
|
@ -1,10 +1,50 @@
|
|||
+++
|
||||
title="Create dependency layers"
|
||||
weight=99
|
||||
weight=3
|
||||
+++
|
||||
|
||||
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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
This page is a stub! The CNB project is applying to [Google Season of Docs](https://developers.google.com/season-of-docs/docs/timeline) to receive support for improving our documentation. Please check back soon.
|
||||
That is, each directory can be used for any of the following purposes:
|
||||
|
||||
If you are familiar with this content and would like to make a contribution, please feel free to open a PR :)
|
||||
| Layer Type | |
|
||||
|------------|-------------------------------------------------------------------------------------------------------------|
|
||||
| `Launch` | the directory will be included in the **final app image** as a single layer |
|
||||
| `Cache` | the directory will be included in the **build cache** and restored to the `CNB_LAYERS_DIR` on future builds |
|
||||
| `Build` | the directory will be accessible to **buildpacks that follow** in the build (via the environment) |
|
||||
|
||||
A buildpack can control how a layer will be used by creating a `<layer>.toml` with a name matching the directory it describes in the `CNB_LAYERS_DIR`.
|
||||
|
||||
### Example
|
||||
|
||||
A buildpack might create a `$CNB_LAYERS_DIR/python` directory and a `$CNB_LAYERS_DIR/python.toml` with the following contents:
|
||||
|
||||
```
|
||||
launch = true
|
||||
cache = true
|
||||
build = true
|
||||
```
|
||||
|
||||
In this example:
|
||||
* the final app image will contain a layer with `python`, as this is needed to run the app
|
||||
* the `$CNB_LAYERS_DIR/python` directory will be pre-created for future builds, avoiding the need to re-download this large dependency
|
||||
* buildpacks that follow in the build will be able to use `python`
|
||||
|
||||
### Example
|
||||
|
||||
This is a simple `./bin/build` script for a buildpack that runs Python's `pip` package manager to resolve dependencies:
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
PIP_LAYER="$CNB_LAYERS_DIR/pip"
|
||||
mkdir -p "$PIP_LAYER/modules" "$PIP_LAYER/env"
|
||||
|
||||
pip install -r requirements.txt -t "$PIP_LAYER/modules" \
|
||||
--install-option="--install-scripts=$PIP_LAYER/bin" \
|
||||
--exists-action=w --disable-pip-version-check --no-cache-dir
|
||||
|
||||
echo "launch = true" > "$PIP_LAYER.toml"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -0,0 +1,111 @@
|
|||
+++
|
||||
title="Get started"
|
||||
weight=1
|
||||
+++
|
||||
|
||||
To write a buildpack, we follow the [Buildpack Specification](https://github.com/buildpacks/spec/blob/main/buildpack.md),
|
||||
which defines the contract between buildpacks and the lifecycle.
|
||||
|
||||
<!--more-->
|
||||
|
||||
A buildpack must contain three files:
|
||||
|
||||
* `buildpack.toml`
|
||||
* `bin/detect`
|
||||
* `bin/build`
|
||||
|
||||
The two files in `bin/` must be executable.
|
||||
They can be shell scripts written in a language like Bash,
|
||||
or they can be executables compiled from a language like Go.
|
||||
|
||||
## `buildpack.toml`
|
||||
|
||||
A buildpack must contain a `buildpack.toml` file in its root directory.
|
||||
|
||||
### Example
|
||||
|
||||
```
|
||||
api = "0.10"
|
||||
|
||||
[buildpack]
|
||||
id = "example.com/python"
|
||||
version = "1.0"
|
||||
|
||||
# Targets the buildpack will work with
|
||||
[[targets]]
|
||||
os = "linux"
|
||||
|
||||
# Stacks (deprecated) the buildpack will work with
|
||||
[[stacks]]
|
||||
id = "io.buildpacks.stacks.jammy"
|
||||
```
|
||||
|
||||
For more information, see [buildpack config](/docs/reference/config/buildpack-config).
|
||||
|
||||
## `bin/detect`
|
||||
|
||||
### Usage
|
||||
|
||||
```
|
||||
bin/detect
|
||||
```
|
||||
|
||||
### Summary
|
||||
|
||||
`bin/detect` is used to determine if a buildpack can work with a given codebase.
|
||||
It will often check for the existence of a particular file,
|
||||
or some configuration indicating what kind of application has been provided.
|
||||
|
||||
Two environment variables identify important file system paths:
|
||||
|
||||
* `CNB_PLATFORM_DIR` - a directory containing platform provided configuration, such as environment variables.
|
||||
* `CNB_BUILD_PLAN_PATH` - a path to a file containing the [build plan].
|
||||
|
||||
In addition, the working directory for `bin/detect` is the application directory.
|
||||
|
||||
`bin/detect` must return an exit code of `0` if the codebase can be serviced by this buildpack,
|
||||
and `100` if it cannot.
|
||||
Other exit codes indicate an error during detection.
|
||||
|
||||
### Example
|
||||
|
||||
This is a simple example of a buildpack that detects a Python application
|
||||
by checking for the presence of a `requirements.txt` file:
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
if [ -f requirements.txt ]; then
|
||||
echo "Python Buildpack"
|
||||
exit 0
|
||||
else
|
||||
exit 100
|
||||
fi
|
||||
```
|
||||
|
||||
## `bin/build`
|
||||
|
||||
### Usage
|
||||
|
||||
```
|
||||
bin/build
|
||||
```
|
||||
|
||||
`bin/build` does (all or part of) the work of transforming application source code into a runnable artifact.
|
||||
It will often resolve dependencies, install binary packages, and compile code.
|
||||
Three environment variables identify important file system paths:
|
||||
|
||||
* `CNB_LAYERS_DIR` - a directory that may contain subdirectories representing each layer created by the buildpack in the final image or build cache.
|
||||
* `CNB_PLATFORM_DIR` - a directory containing platform provided configuration, such as environment variables.
|
||||
* `CNB_BP_PLAN_PATH` - a path to a file containing the [build plan].
|
||||
|
||||
In addition, the working directory for `bin/build` is the application directory.
|
||||
|
||||
All changes to the codebase in the working directory will be persisted in the final image,
|
||||
along with any launch layers created in the `CNB_LAYERS_DIR`.
|
||||
|
||||
It is important to note that multiple buildpacks may work together to create the final image,
|
||||
each contributing a subset of the dependencies or configuration needed to run the application.
|
||||
In this way, buildpacks are modular and composable.
|
||||
|
||||
[build plan]: /docs/for-buildpack-authors/how-to/write-buildpacks/use-build-plan
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
+++
|
||||
title="Specify process types"
|
||||
weight=1
|
||||
weight=4
|
||||
+++
|
||||
|
||||
One of the benefits of buildpacks is that they are multi-process - an image can have multiple entrypoints for each operational mode.
|
||||
|
|
|
|||
|
|
@ -1,10 +1,121 @@
|
|||
+++
|
||||
title="Use the build plan"
|
||||
weight=99
|
||||
weight=2
|
||||
+++
|
||||
|
||||
The [Build Plan](https://github.com/buildpacks/spec/blob/main/buildpack.md#build-plan-toml) 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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
This page is a stub! The CNB project is applying to [Google Season of Docs](https://developers.google.com/season-of-docs/docs/timeline) to receive support for improving our documentation. Please check back soon.
|
||||
During the `detect` phase, each buildpack may write something it `requires` or `provides` (or both) into the Build Plan.
|
||||
A buildpack can `require` or `provide` multiple dependencies, and even multiple groupings of dependencies (using `or` lists).
|
||||
Additionally, multiple buildpacks may `require` or `provide` the same dependency.
|
||||
For detailed information, consult the [spec](https://github.com/buildpacks/spec/blob/main/buildpack.md#buildpack-plan-toml).
|
||||
|
||||
If you are familiar with this content and would like to make a contribution, please feel free to open a PR :)
|
||||
The lifecycle uses the Build Plan to determine whether a particular list of buildpacks can work together,
|
||||
by seeing whether all dependencies required can be provided by that list.
|
||||
|
||||
Later, during the `build` phase, each buildpack may read the Buildpack Plan (a condensed version of the Build Plan, composed by the lifecycle) to determine what it should do.
|
||||
|
||||
Let's see how this works with an example.
|
||||
|
||||
### Example: `node-engine` buildpack
|
||||
|
||||
Let's walk through some possible cases a `node-engine` buildpack may consider:
|
||||
|
||||
1. Nothing in the app explicitly calls out that it is needed
|
||||
2. It is explicitly referred to in some configuration file
|
||||
|
||||
We will also consider what an `NPM` and a `JVM` buildpack may do.
|
||||
|
||||
#### Scenario 1: No Explicit Request
|
||||
|
||||
A `node-engine` buildpack is always happy to `provide` the `node` dependency. The build plan it will write may look something like:
|
||||
```
|
||||
[[provides]]
|
||||
name = "node"
|
||||
```
|
||||
> **NOTE:** If this was the only buildpack running, this would fail the `detect` phase. In order to pass, every `provides` must be matched up with a `requires`, whether in the same buildpack or in another buildpack.
|
||||
> See the [spec](https://github.com/buildpacks/spec/blob/main/buildpack.md#phase-1-detection) for particulars on how ordering buildpacks can adjust detection results.
|
||||
|
||||
#### Scenario 2: One Version Requested
|
||||
|
||||
During the `detect` phase, the `node-engine` buildpack sees in one configuration file (e.g. a `.nvmrc` file in the app directory) that `node v10.x` is explicitly requested by the application. Seeing that, it may write the below text to the build plan:
|
||||
```
|
||||
[[provides]]
|
||||
name = "node"
|
||||
|
||||
[[requires]]
|
||||
name = "node"
|
||||
version = "10.x"
|
||||
|
||||
[requires.metadata]
|
||||
version-source = ".nvmrc"
|
||||
```
|
||||
|
||||
As always, the buildpack `provides` `node`. In this particular case, a version of `node` (`10.x`) is being requested in a configuration file (`.nvmrc`). The buildpack chooses to add an additional piece of metadata (`version-source`), so that it can understand where that request came from.
|
||||
|
||||
#### NPM Buildpack
|
||||
|
||||
`NPM` is the default package manager for `node`. A NPM Buildpack may ensure that all the packages for the application are present (by running `npm install`), and perhaps cache those packages as well, to optimize future builds.
|
||||
|
||||
NPM is typically distributed together with node. As a result, a NPM buildpack may require `node`, but not want to `provide` it, trusting that the `node-engine` buildpack will be in charge of `providing` `node`.
|
||||
|
||||
The NPM buildpack could write the following to the build plan, if the buildpack sees that `npm` is necessary (e.g., it sees a `package.json` file in the app directory):
|
||||
```
|
||||
[[requires]]
|
||||
name = "node"
|
||||
```
|
||||
|
||||
If, looking in the `package.json` file, the NPM buildpack sees a specific version of `node` requested in the [engines](https://docs.npmjs.com/files/package.json#engines) field (e.g. `14.1`), it may write the following to the build plan:
|
||||
```
|
||||
[[requires]]
|
||||
name = "node"
|
||||
version = "14.1"
|
||||
|
||||
[requires.metadata]
|
||||
version-source = "package.json"
|
||||
```
|
||||
|
||||
> **NOTE:** As above, if this was the only buildpack running, this would fail the `detect` phase. In order to pass, every `provides` must be matched up with a `requires`, whether in the same buildpack or in another buildpack.
|
||||
> See the [spec](https://github.com/buildpacks/spec/blob/main/buildpack.md#phase-1-detection) for particulars on how ordering buildpacks can adjust detection results.
|
||||
|
||||
However, if the NPM Buildpack was run together with the Node Engine buildpack (which `provides` `node`), the lifecycle will see that all requirements are fulfilled, and select that group as the correct set of buildpacks.
|
||||
|
||||
### Example: JVM buildpack
|
||||
|
||||
Java is distributed in two formats - the `jdk` (Java Development Kit), which allows for compilation and running of Java programs, and the `jre` (Java Runtime Environment, which allows for running compiled Java programs).
|
||||
A very naive implementation of the buildpack may have it write several `provides` options to the build plan, detailing everything that it can provide,
|
||||
while later buildpacks would figure out based on the application which options it requires, and would `require` those.
|
||||
In this particular case, we can use the `or` operator to present different possible build plans the buildpack can follow:
|
||||
|
||||
```
|
||||
# option 1 (`jre` and `jdk`)
|
||||
[[provides]]
|
||||
name = "jre"
|
||||
|
||||
[[provides]]
|
||||
name = "jdk"
|
||||
|
||||
# option 2 (or just `jdk`)
|
||||
[[or]]
|
||||
[[or.provides]]
|
||||
name = "jdk"
|
||||
|
||||
# option 3 (or just `jre`)
|
||||
[[or]]
|
||||
[[or.provides]]
|
||||
name = "jre"
|
||||
```
|
||||
|
||||
The buildpack gives three options to the lifecycle:
|
||||
* It can provide a standalone `jre`
|
||||
* It can provide a standalone `jdk`
|
||||
* It can provide both the `jdk` and `jre`
|
||||
|
||||
As with the other buildpacks, this alone will not be sufficient for the lifecycle. However, other buildpacks that follow may `require` certain things.
|
||||
|
||||
For example, another buildpack may look into the application and, seeing that it is a Java executable, `require` the `jre` in order to run it.
|
||||
When the lifecycle analyzes the results of the `detect` phase, it will see that there is a buildpack which provides `jre`, and a buildpack that requires `jre`,
|
||||
and will therefore conclude that those options represent a valid set of buildpacks.
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ We also create a `package.json` file with the following contents:
|
|||
<!-- test:file=node-js-sample-app/package.json -->
|
||||
```javascript
|
||||
{
|
||||
name = "example-application"
|
||||
"name": "example-application"
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -110,4 +110,4 @@ A new image named `test-node-js-app` was created in your Docker daemon with a la
|
|||
<a href="/docs/for-buildpack-authors/tutorials/basic-buildpack/05_make-app-runnable" class="button bg-pink">Next Step</a>
|
||||
<!--+end+-->
|
||||
|
||||
[layers-dir]: /docs/reference/spec/buildpack-api/#layers
|
||||
[layers-dir]: /docs/for-buildpack-authors/how-to/write-buildpacks/create-layer
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ You should see something akin to the following:
|
|||
API except where noted. Consult the [spec](https://github.com/buildpacks/spec/blob/main/image_extension.md)
|
||||
for further details.
|
||||
* `./bin/detect` is invoked during the `detect` phase. It analyzes application source code to determine if the extension
|
||||
is needed and contributes [build plan](/docs/reference/spec/buildpack-api/#build-plan) entries (much like a
|
||||
is needed and contributes [build plan] entries (much like a
|
||||
buildpack `./bin/detect`). Just like for buildpacks, a `./bin/detect` that exits with code `0` is considered to have
|
||||
passed detection, and fails otherwise.
|
||||
* `./bin/generate` is invoked during the `generate` phase (a new lifecycle phase that happens after `detect`). It
|
||||
|
|
@ -51,3 +51,5 @@ For guidance around writing extensions and more advanced use cases, see [here](/
|
|||
|
||||
<a href="/docs/for-buildpack-authors/tutorials/basic-extension/04_build-dockerfile" class="button bg-pink">Next Step</a>
|
||||
<!--+ end +-->
|
||||
|
||||
[build plan]: /docs/for-buildpack-authors/how-to/write-buildpacks/use-build-plan
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
+++
|
||||
title="Concepts"
|
||||
weight=1
|
||||
weight=2
|
||||
include_summaries=true
|
||||
+++
|
||||
|
|
@ -12,7 +12,7 @@ a build-time base image, a [lifecycle] binary, and a reference to a runtime base
|
|||
|
||||
<!--more-->
|
||||
|
||||
|
||||
|
||||
|
||||
## Anatomy of a builder
|
||||
|
||||
|
|
|
|||
|
|
@ -1,51 +0,0 @@
|
|||
|
||||
+++
|
||||
title="What is a buildpack?"
|
||||
aliases=[
|
||||
"/docs/concepts/components/buildpack"
|
||||
]
|
||||
weight=1
|
||||
+++
|
||||
|
||||
A `buildpack` is software that examines your source code and determines the best way to build it.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Typical buildpacks consist of at least three files:
|
||||
|
||||
* `buildpack.toml` -- provides metadata about your buildpack
|
||||
* `bin/detect` -- determines whether buildpack should be applied
|
||||
* `bin/build` -- executes build logic
|
||||
|
||||
#### Meta-buildpack
|
||||
|
||||
There is a different type of buildpack commonly referred to as a **meta-buildpack**. It contains only a
|
||||
`buildpack.toml` file with an `order` configuration that references other buildpacks. This is useful for
|
||||
composing more complex detection strategies.
|
||||
|
||||
## Buildpack phases
|
||||
|
||||
There are two essential steps that allow buildpacks to create a runnable image.
|
||||
|
||||
#### Detect
|
||||
|
||||
A [platform][platform] sequentially tests [groups][buildpack-group] of buildpacks against your app's source code. The first group that deems itself fit for your source code will become the selected set of buildpacks for your app.
|
||||
|
||||
Detection criteria is specific to each buildpack -- for instance, an **NPM buildpack** might look for a `package.json`, and a **Go buildpack** might look for Go source files.
|
||||
|
||||
#### Build
|
||||
|
||||
During build the buildpacks contribute to the final application image. This contribution could be as simple as setting some environment variables within the image, creating a layer containing a binary (e.g: node, python, or ruby), or adding app dependencies (e.g: running `npm install`, `pip install -r requirements.txt`, or `bundle install`).
|
||||
|
||||
## Distribution
|
||||
|
||||
Buildpacks can be [packaged][package-a-buildpack] as OCI images on an image registry or Docker daemon. This includes meta-buildpacks.
|
||||
|
||||
## Reference
|
||||
|
||||
Learn more about buildpacks by referring to the [Buildpack API][buildpack-api].
|
||||
|
||||
[buildpack-api]: /docs/reference/buildpack-api
|
||||
[buildpack-group]: /docs/for-buildpack-authors/concepts/buildpack-group/
|
||||
[package-a-buildpack]: /docs/for-buildpack-authors/how-to/distribute-buildpacks/package-buildpack/
|
||||
[platform]: /docs/for-app-developers/concepts/platform
|
||||
|
|
@ -1,116 +0,0 @@
|
|||
|
||||
+++
|
||||
title="What are image extensions?"
|
||||
aliases=[
|
||||
"/docs/features/dockerfiles"
|
||||
]
|
||||
weight=99
|
||||
+++
|
||||
|
||||
Image extensions generate Dockerfiles that can be used to extend base images for buildpacks builds.
|
||||
|
||||
<!--more-->
|
||||
|
||||
## Why Dockerfiles?
|
||||
|
||||
Buildpacks can do a lot, but there are some things buildpacks can't do. They can't install operating system packages,
|
||||
for example. Why not?
|
||||
|
||||
Buildpacks do not run as the `root` user and cannot make arbitrary changes to the filesystem. This enhances security,
|
||||
enables buildpack interoperability, and preserves the ability to rebase - but it comes at a cost. Base image authors
|
||||
must anticipate the OS-level dependencies that will be needed at build and run-time ahead of time, and this isn't always
|
||||
possible.
|
||||
|
||||
This has been a longstanding source of [discussion](https://github.com/buildpacks/rfcs/pull/173) within the CNB project:
|
||||
how can we preserve the benefits of buildpacks while enabling more powerful capabilities?
|
||||
|
||||
## Buildpacks and Dockerfiles can work together
|
||||
|
||||
Buildpacks are often presented as an alternative to Dockerfiles, but we think buildpacks and Dockerfiles can work
|
||||
together.
|
||||
|
||||
Buildpacks are optimized for creating layers that are efficient and logically mapped to the dependencies that they
|
||||
provide. By contrast, Dockerfiles are the most-used and best-understood mechanism for constructing base images and
|
||||
installing OS-level dependencies for containers.
|
||||
|
||||
The CNB Dockerfiles feature allows Dockerfiles to "provide" dependencies that buildpacks "require" through a
|
||||
shared [build plan](/docs/reference/spec/buildpack-api/#build-plan), by introducing the concept of image extensions.
|
||||
|
||||
## What are image extensions?
|
||||
|
||||
Image extensions are buildpack-like components that use a restricted `Dockerfile` syntax to expand base images. Their
|
||||
purpose is to generate Dockerfiles that can be used to extend the builder or run images prior to buildpacks builds.
|
||||
|
||||
Like buildpacks, extensions participate in the `detect` phase - analyzing application source code to determine if they
|
||||
are needed. During `detect`, extensions can contribute to
|
||||
the [build plan](/docs/reference/spec/buildpack-api/#build-plan) - recording dependencies that they are able to "
|
||||
provide" (though unlike buildpacks, they can't "require" anything).
|
||||
|
||||
If the provided order contains extensions, the output of `detect` will be a group of image extensions and a group of
|
||||
buildpacks that together produce a valid build plan. Image extensions only generate Dockerfiles - they don't create
|
||||
layers or participate in the `build` phase.
|
||||
|
||||
An image extension could be defined with the following directory:
|
||||
|
||||
```
|
||||
.
|
||||
├── extension.toml <- similar to a buildpack buildpack.toml
|
||||
├── bin
|
||||
│ ├── detect <- similar to a buildpack ./bin/detect
|
||||
│ ├── generate <- similar to a buildpack ./bin/build
|
||||
```
|
||||
|
||||
* The `extension.toml` describes the extension, containing information such as its name, ID, and version.
|
||||
* `./bin/detect` is invoked during the `detect` phase. It analyzes application source code to determine if the extension
|
||||
is needed and contributes build plan entries.
|
||||
* `./bin/generate` is invoked during the `generate` phase (a new lifecycle phase that happens after `detect`). It
|
||||
outputs either or both of `build.Dockerfile` or `run.Dockerfile` for extending the builder or run image.
|
||||
|
||||
For more information and to see a build in action,
|
||||
see [authoring an image extension](/docs/for-buildpack-authors/tutorials/basic-extension).
|
||||
|
||||
## A platform's perspective
|
||||
|
||||
Platforms may wish to use image extensions if they wish to provide the flexibility of modifying base images dynamically
|
||||
at build time.
|
||||
|
||||
### Risks
|
||||
|
||||
Image extensions are considered experimental and susceptible to change in future API versions. However, image extension
|
||||
should be **used with great care**. Platform operators should be mindful that:
|
||||
|
||||
* Dockerfiles are very powerful - in fact, you can do anything with a Dockerfile! Introducing image extensions into your
|
||||
CNB builds can eliminate the security and compatibility guarantees that buildpacks provide.
|
||||
* When Dockerfiles are used to switch the run image from that defined on the provided builder, the resulting run image
|
||||
may not have all the mixins required by buildpacks that detected. Platforms may wish to optionally re-validate mixins
|
||||
prior to `build` when using extensions.
|
||||
|
||||
### Putting it all together
|
||||
|
||||
The ordering of lifecycle phases looks like the following:
|
||||
|
||||
* `analyze`
|
||||
* `detect` - after standard detection, `detect` will also run extensions' `./bin/generate`; output Dockerfiles are
|
||||
written to a volume
|
||||
* `restore`
|
||||
* `extend` - applies one or more `build.Dockerfile`s to the builder image
|
||||
* `extend` - applies one or more `run.Dockerfile`s to the run image (could run in parallel with builder image extension)
|
||||
* `build`
|
||||
* `export`
|
||||
|
||||
For more information, consult the [migration guide](/docs/for-platform-operators/how-to/migrate/platform-api-0.9-0.10).
|
||||
|
||||
#### Platform support for Dockerfiles
|
||||
|
||||
Supported:
|
||||
|
||||
* [pack cli](https://github.com/buildpacks/pack) (prefer version `0.30.0` and above)
|
||||
|
||||
Needs support:
|
||||
|
||||
* [Tekton task](https://github.com/tektoncd/catalog/tree/main/task/buildpacks-phases/0.2) ([GitHub issue](https://github.com/tektoncd/catalog/issues/1096))
|
||||
* [kpack](https://github.com/pivotal/kpack) ([GitHub issue](https://github.com/pivotal/kpack/issues/1047))
|
||||
|
||||
Your feedback is appreciated! As the feature evolves, we want to hear from you - what's going well, what's challenging,
|
||||
and anything else you'd like to see. Please reach out in [Slack](https://cncf.slack.io) (#buildpacks channel)
|
||||
or [GitHub](https://github.com/buildpacks).
|
||||
|
|
@ -1,6 +1,5 @@
|
|||
+++
|
||||
title="How To"
|
||||
weight=3
|
||||
|
||||
include_summaries=true
|
||||
+++
|
||||
|
|
|
|||
|
|
@ -59,12 +59,14 @@ image = "cnbs/sample-base-build:jammy"
|
|||
[run]
|
||||
[[run.images]]
|
||||
image = "cnbs/sample-base-run:jammy"
|
||||
mirrors = ["other-registry.example.com/cnbs/sample-base-run:jammy"]
|
||||
|
||||
# Stack (deprecated) used to create the builder
|
||||
[stack]
|
||||
id = "io.buildpacks.samples.stacks.jammy"
|
||||
# This image is used at runtime
|
||||
run-image = "cnbs/sample-base-run:jammy"
|
||||
run-image-mirrors = ["other-registry.example.com/cnbs/sample-base-run:jammy"]
|
||||
# This image is used at build-time
|
||||
build-image = "cnbs/sample-base-build:jammy"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
title="Pack"
|
||||
aliases=[
|
||||
"/docs/install-pack/",
|
||||
"/docs/tools/pack/_index",
|
||||
"/docs/tools/pack/",
|
||||
"/docs/tools/pack/cli/install/"
|
||||
]
|
||||
weight=1
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
+++
|
||||
title="CLI Docs"
|
||||
aliases=[
|
||||
"/docs/tools/pack/cli/_index"
|
||||
"/docs/tools/pack/cli/"
|
||||
]
|
||||
include_summaries=true
|
||||
+++
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
+++
|
||||
title="Concepts"
|
||||
aliases=[
|
||||
"/docs/tools/pack/concepts/_index"
|
||||
"/docs/tools/pack/concepts/"
|
||||
]
|
||||
include_summaries=true
|
||||
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ For processes from older buildpacks, upgrading the platform will not change the
|
|||
|
||||
### Image extensions are supported (experimental)
|
||||
|
||||
Platform 0.10 introduces image extensions as experimental components for customizing build and run-time base images (see [here](/docs/for-platform-operators/concepts/dockerfiles) 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.
|
||||
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). 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
+++
|
||||
title="Configuration"
|
||||
include_summaries=true
|
||||
|
||||
+++
|
||||
|
|
@ -1,12 +1,16 @@
|
|||
+++
|
||||
title="builder.toml"
|
||||
summary="Schema of the builder config file."
|
||||
aliases=[
|
||||
"/docs/reference/builder-config/"
|
||||
]
|
||||
weight=2
|
||||
+++
|
||||
|
||||
A [builder][builder] configuration schema is as follows:
|
||||
The builder config file is used for creating [builders][builder].
|
||||
|
||||
<!--more-->
|
||||
|
||||
The schema is as follows:
|
||||
|
||||
- #### `description` _(string, optional)_
|
||||
A human-readable description of the builder, to be shown in `builder inspect` output
|
||||
|
|
@ -26,7 +30,7 @@ A [builder][builder] configuration schema is as follows:
|
|||
|
||||
- #### `order` _(list, required)_
|
||||
A list of buildpack groups. This list determines the order in which groups of buildpacks
|
||||
will be tested during detection. Detection is a phase of the [lifecycle][lifecycle] where
|
||||
will be tested during detection. Detection is a phase of the [lifecycle] where
|
||||
buildpacks are tested, one group at a time, for compatibility with the provided application source code. The first
|
||||
group whose non-optional buildpacks all pass detection will be the group selected for the remainder of the build. Each
|
||||
group currently contains a single required field:
|
||||
|
|
@ -85,7 +89,7 @@ A [builder][builder] configuration schema is as follows:
|
|||
[Run image mirrors](/docs/for-app-developers/concepts/base-images/run#run-image-mirrors) for the stack
|
||||
|
||||
- #### `lifecycle` _(optional)_
|
||||
The [lifecycle][lifecycle] to embed into the builder. It must contain **at most one** the following fields:
|
||||
The [lifecycle] to embed into the builder. It must contain **at most one** the following fields:
|
||||
|
||||
- **`version`** _(string, optional)_\
|
||||
The version of the lifecycle (semver format) to download. If specified, `uri` must not be provided.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,112 @@
|
|||
+++
|
||||
title="buildpack.toml"
|
||||
weight=3
|
||||
+++
|
||||
|
||||
The buildpack configuration file is a necessary component of a [buildpack].
|
||||
|
||||
<!--more-->
|
||||
|
||||
The schema is as follows:
|
||||
|
||||
- **`api`** _(string, required, current: `0.10`)_\
|
||||
The Buildpack API version the buildpack adheres to. Used to ensure [compatibility](/docs/reference/spec/buildpack-api#api-compatibility) against
|
||||
the [lifecycle].
|
||||
|
||||
> Not to be confused with Cloud Foundry or Heroku buildpack versions.
|
||||
> This version pertains to the interface between the [buildpack] and the [lifecycle] of Cloud Native Buildpacks.
|
||||
|
||||
- **`buildpack`** _(required)_\
|
||||
Information about the buildpack.
|
||||
|
||||
- **`id`** _(string, required)_\
|
||||
A globally unique identifier.
|
||||
|
||||
- **`version`** _(string, required)_\
|
||||
The version of the buildpack.
|
||||
|
||||
- **`name`** _(string, required)_\
|
||||
Human readable name.
|
||||
|
||||
- **`clear-env`** _(boolean, optional, default: `false`)_\
|
||||
Clears user-defined environment variables when `true` on executions of `bin/detect` and `bin/build`.
|
||||
|
||||
- **`homepage`** _(string, optional)_\
|
||||
Buildpack homepage.
|
||||
|
||||
- **`description`** _(string, optional)_\
|
||||
A short description of the buildpack.
|
||||
|
||||
- **`keywords`** _(string(s), optional)_\
|
||||
Keywords to help locate the buildpack. These can be useful if publishing to the [Buildpack Registry](https://registry.buildpacks.io/).
|
||||
|
||||
- **`sbom-formats`** _(string(s), optional)_\
|
||||
SBOM formats output by the buildpack. Supported values are the following media types: `application/vnd.cyclonedx+json`, `application/spdx+json`, and `application/vnd.syft+json`.
|
||||
|
||||
- **`licenses`** _(list, optional)_\
|
||||
A list of licenses pertaining to the buildpack.
|
||||
|
||||
- **`type`** _(string, optional)_\
|
||||
The type of the license. This may use the [SPDX 2.1 license expression](https://spdx.org/spdx-specification-21-web-version), but it is not limited to identifiers in the [SPDX Licenses List](https://spdx.org/licenses/). If the buildpack is using a nonstandard license, then the `uri` key may be specified in lieu of or in addition to `type` to point to the license.
|
||||
|
||||
- **`uri`** _(string, optional)_\
|
||||
A URL or path to the license.
|
||||
|
||||
- **`targets`** _(list, optional)_\
|
||||
A list of targets supported by the buildpack.
|
||||
When no targets are specified, the `os`/`arch` will be inferred from the contents of the `./bin` directory
|
||||
(`./bin/build` implies `linux`/`amd64` and `./bin/build.bat` implies `windows`/`amd64`).
|
||||
For each target, all fields are optional (though at least one should be provided).
|
||||
_Cannot be used in conjunction with `order` list._
|
||||
|
||||
- **`os`** _(string, optional)_\
|
||||
The supported operating system name.
|
||||
|
||||
- **`arch`** _(string, optional)_\
|
||||
The supported architecture.
|
||||
|
||||
- **`variant`** _(string, optional)_\
|
||||
The supported architecture variant.
|
||||
|
||||
- **`targets.distros`** _(optional)_\
|
||||
A list of supported distributions for the given operating system, architecture, and architecture variant.
|
||||
|
||||
- **`name`** _(string, optional)_\
|
||||
The supported operating system distribution name.
|
||||
|
||||
- **`version`** _(string, optional)_\
|
||||
The supported operating system distribution version.
|
||||
|
||||
- **`stacks`** _(list, deprecated, optional)_\
|
||||
A list of stacks supported by the buildpack.
|
||||
_Cannot be used in conjunction with `order` list._
|
||||
|
||||
- **`id`** _(string, required)_\
|
||||
The id of the supported stack.
|
||||
|
||||
- **`mixins`** _(string list, required)_\
|
||||
A list of mixins required on the stack images.
|
||||
|
||||
- **`order`** _(list, optional)_\
|
||||
A list of buildpack groups for the purpose of creating a [meta-buildpack][meta-buildpack]. This list determines the
|
||||
order in which groups of buildpacks will be tested during detection. _If omitted, `targets` or `stacks` list must be present.
|
||||
Cannot be used in conjunction with `targets` or `stacks` list._
|
||||
|
||||
- **`group`** _(list, required)_\
|
||||
A list of buildpack references.
|
||||
|
||||
- **`id`** _(string, required)_\
|
||||
The identifier of a buildpack being referred to.
|
||||
Buildpacks with the same ID may appear in multiple groups at once but never in the same group.
|
||||
|
||||
- **`version`** _(string, required)_\
|
||||
The version of the buildpack being referred to.
|
||||
|
||||
- **`optional`** _(boolean, optional, default: `false`)_\
|
||||
Whether this buildpack is optional during detection.
|
||||
|
||||
- **`metadata`** _(any, optional)_\
|
||||
Arbitrary data for buildpack.
|
||||
|
||||
[buildpack]: /docs/for-buildpack-authors/concepts/buildpack
|
||||
[lifecycle]: /docs/for-buildpack-authors/concepts/lifecycle-phases
|
||||
|
|
@ -1,12 +1,16 @@
|
|||
+++
|
||||
title="package.toml"
|
||||
summary="Schema of the buildpack package config file."
|
||||
aliases=[
|
||||
"/docs/reference/package-config/",
|
||||
]
|
||||
weight=4
|
||||
+++
|
||||
|
||||
A [buildpackage][package] configuration schema is as follows:
|
||||
The package config file is used for packaging buildpacks for distribution as OCI images or tar files.
|
||||
|
||||
<!--more-->
|
||||
|
||||
The schema is as follows:
|
||||
|
||||
- #### `buildpack` _(required)_
|
||||
The buildpack to package. It must contain the following field:
|
||||
|
|
@ -33,4 +37,4 @@ You can view [sample buildpackages](https://github.com/buildpacks/samples/tree/m
|
|||
|
||||
[package]: /docs/for-platform-operators/concepts/buildpack#distribution
|
||||
[supported-archives]: /docs/reference/builder-config#supported-archives
|
||||
[order-group]: /docs/reference/spec/buildpack-api/#schema
|
||||
[order-group]: https://github.com/buildpacks/spec/blob/main/buildpack.md#order-resolution
|
||||
|
|
|
|||
|
|
@ -1,18 +1,22 @@
|
|||
+++
|
||||
title="project.toml"
|
||||
summary="Schema of the project descriptor file."
|
||||
aliases=[
|
||||
"/docs/reference/project-descriptor/"
|
||||
]
|
||||
weight=1
|
||||
+++
|
||||
|
||||
A project descriptor allows users to detail configuration for apps, services, functions and buildpacks. It should, by
|
||||
default, be named `project.toml`, though users can name it differently, and pass the filename to `pack` by calling
|
||||
The project descriptor file allows app developers to provide configuration for apps, services, functions and buildpacks.
|
||||
|
||||
<!--more-->
|
||||
|
||||
It should, by default, be named `project.toml`, though users can name it differently, and pass the filename to `pack` by calling
|
||||
|
||||
```shell script
|
||||
$ pack build --descriptor <project-descriptor path>
|
||||
```
|
||||
|
||||
The schema for the `project descriptor` is:
|
||||
The schema is as follows:
|
||||
|
||||
- #### `_` _(table, optional)_
|
||||
A configuration table for a project.
|
||||
|
|
|
|||
|
|
@ -4,11 +4,10 @@ include_summaries=true
|
|||
expand=true
|
||||
+++
|
||||
|
||||
This section provides an overview of the Cloud Native Buildpack API specification.
|
||||
The Cloud Native Buildpacks specification defines the APIs that buildpacks, platforms, and the lifecycle must implement.
|
||||
|
||||
Most buildpack users won't need this information unless they are writing a buildpack or
|
||||
a platform that supports buildpacks.
|
||||
Most buildpack users won't need this information unless they are writing a buildpack or a platform that supports buildpacks.
|
||||
|
||||
<!--more-->
|
||||
|
||||
The Cloud Native Buildpack API specification consists of the following parts:
|
||||
The specification consists of the following:
|
||||
|
|
|
|||
|
|
@ -1,394 +1,27 @@
|
|||
+++
|
||||
title="Buildpack API"
|
||||
+++ title="Buildpack API"
|
||||
aliases=[
|
||||
"/docs/reference/buildpack-api/"
|
||||
"/docs/reference/buildpack-api/"
|
||||
]
|
||||
+++
|
||||
|
||||
This specification defines the interface between a buildpack and the environment that runs it.
|
||||
This API will be used by buildpack authors.
|
||||
The Buildpack API specifies the interface between a [lifecycle] program and one or more [buildpacks][buildpack].
|
||||
|
||||
<!--more-->
|
||||
|
||||
A buildpack must contain three files:
|
||||
|
||||
* `buildpack.toml`
|
||||
* `bin/detect`
|
||||
* `bin/build`
|
||||
|
||||
The two files in `bin/` must be executable. They can be shell scripts written in a language like Bash or they
|
||||
can be executables compiled from a language like Go.
|
||||
|
||||
## `bin/detect`
|
||||
|
||||
### Usage
|
||||
|
||||
```
|
||||
bin/detect
|
||||
```
|
||||
|
||||
### Summary
|
||||
|
||||
This entrypoint is used to determine if a buildpack should
|
||||
run against a given codebase. It will often check for the existence of a particular
|
||||
file or some configuration indicating what kind of application has been provided.
|
||||
Two environment variables identify important file system paths:
|
||||
|
||||
* `CNB_PLATFORM_DIR` - a directory containing platform provided configuration, such as environment variables.
|
||||
* `CNB_BUILD_PLAN_PATH` - a path to a file containing the [Build Plan](#build-plan).
|
||||
|
||||
In addition, the working directory is defined as the location of the codebase
|
||||
the buildpack will execute against.
|
||||
|
||||
The executable must return an exit code of `0` if the codebase can be serviced by this buildpack, and `100` if it cannot.
|
||||
Other exit codes indicate an error during detection.
|
||||
|
||||
### Example
|
||||
|
||||
This is a simple example of a buildpack that detects a Python application by
|
||||
checking for the presence of a `requirements.txt` file:
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
if [ -f requirements.txt ]; then
|
||||
echo "Python Buildpack"
|
||||
exit 0
|
||||
else
|
||||
exit 100
|
||||
fi
|
||||
```
|
||||
|
||||
## `bin/build`
|
||||
|
||||
### Usage
|
||||
|
||||
```
|
||||
bin/build
|
||||
```
|
||||
|
||||
This entrypoint transforms a codebase.
|
||||
It will often resolve dependencies, install binary packages, and compile code.
|
||||
Three environment variables identify important file system paths:
|
||||
|
||||
* `CNB_LAYERS_DIR` - a directory that may contain subdirectories representing each layer created by the buildpack in the final image or build cache.
|
||||
* `CNB_PLATFORM_DIR` - a directory containing platform provided configuration, such as environment variables.
|
||||
* `CNB_BP_PLAN_PATH` - a path to a file containing the [Build Plan](#build-plan).
|
||||
|
||||
In addition, the working directory is defined as the location of the codebase
|
||||
this buildpack will execute against.
|
||||
|
||||
All changes to the codebase in the working directory will be included in the final
|
||||
image, along with any launch layers created in the `CNB_LAYERS_DIR`.
|
||||
|
||||
#### Layers
|
||||
|
||||
Each directory created by the buildpack under the `CNB_LAYERS_DIR` can be used for any
|
||||
of the following purposes:
|
||||
|
||||
* Launch - the directory will be included in the run image as a single layer
|
||||
* Cache - the directory will be included in the cache
|
||||
* Build - the directory will be accessible by subsequent buildpacks
|
||||
|
||||
A buildpack defines how a layer will by used by creating a `<layer>.toml` with
|
||||
a name matching the directory it describes in the `CNB_LAYERS_DIR`. For example, a
|
||||
buildpack might create a `$CNB_LAYERS_DIR/python` directory and a `$CNB_LAYERS_DIR/python.toml`
|
||||
with the following contents:
|
||||
|
||||
```
|
||||
launch = true
|
||||
cache = true
|
||||
build = true
|
||||
```
|
||||
|
||||
In this example, the `python` directory will be included in the run image,
|
||||
cached for future builds, and will be accessible to subsequent buildpacks.
|
||||
|
||||
### Example
|
||||
|
||||
This is a simple example of a buildpack that runs Python's `pip` package manager
|
||||
to resolve dependencies:
|
||||
|
||||
```
|
||||
#!/bin/sh
|
||||
|
||||
PIP_LAYER="$CNB_LAYERS_DIR/pip"
|
||||
mkdir -p "$PIP_LAYER/modules" "$PIP_LAYER/env"
|
||||
|
||||
pip install -r requirements.txt -t "$PIP_LAYER/modules" \
|
||||
--install-option="--install-scripts=$PIP_LAYER/bin" \
|
||||
--exists-action=w --disable-pip-version-check --no-cache-dir
|
||||
|
||||
echo "launch = true" > "$PIP_LAYER.toml"
|
||||
```
|
||||
|
||||
## `buildpack.toml`
|
||||
|
||||
A buildpack must contain a `buildpack.toml` file in its root directory.
|
||||
|
||||
|
||||
### Example
|
||||
|
||||
```
|
||||
api = "0.10"
|
||||
|
||||
[buildpack]
|
||||
id = "example.com/python"
|
||||
version = "1.0"
|
||||
|
||||
# Targets the buildpack will work with
|
||||
[[targets]]
|
||||
os = "linux"
|
||||
|
||||
# Stacks (deprecated) the buildpack will work with
|
||||
[[stacks]]
|
||||
id = "io.buildpacks.stacks.jammy"
|
||||
```
|
||||
|
||||
### Schema
|
||||
|
||||
The schema is as follows:
|
||||
- **`api`** _(string, required, current: `0.10`)_\
|
||||
The Buildpack API version the buildpack adheres to. Used to ensure [compatibility](#api-compatibility) against
|
||||
the [lifecycle][lifecycle].
|
||||
|
||||
> Not to be confused with Cloud Foundry or Heroku buildpack versions. This version pertains to the interface
|
||||
> between the [buildpack][buildpack] and the [lifecycle][lifecycle] of Cloud Native Buildpacks.
|
||||
|
||||
- **`buildpack`** _(required)_\
|
||||
Information about the buildpack.
|
||||
|
||||
- **`id`** _(string, required)_\
|
||||
A globally unique identifier.
|
||||
|
||||
- **`version`** _(string, required)_\
|
||||
The version of the buildpack.
|
||||
|
||||
- **`name`** _(string, required)_\
|
||||
Human readable name.
|
||||
|
||||
- **`clear-env`** _(boolean, optional, default: `false`)_\
|
||||
Clears user-defined environment variables when `true` on executions of `bin/detect` and `bin/build`.
|
||||
|
||||
- **`homepage`** _(string, optional)_\
|
||||
Buildpack homepage.
|
||||
|
||||
- **`description`** _(string, optional)_\
|
||||
A short description of the buildpack.
|
||||
|
||||
- **`keywords`** _(string(s), optional)_\
|
||||
Keywords to help locate the buildpack. These can be useful if publishing to the [Buildpack Registry](https://registry.buildpacks.io/).
|
||||
|
||||
- **`sbom-formats`** _(string(s), optional)_\
|
||||
SBOM formats output by the buildpack. Supported values are the following media types: `application/vnd.cyclonedx+json`, `application/spdx+json`, and `application/vnd.syft+json`.
|
||||
|
||||
- **`licenses`** _(list, optional)_\
|
||||
A list of licenses pertaining to the buildpack.
|
||||
|
||||
- **`type`** _(string, optional)_\
|
||||
The type of the license. This may use the [SPDX 2.1 license expression](https://spdx.org/spdx-specification-21-web-version), but it is not limited to identifiers in the [SPDX Licenses List](https://spdx.org/licenses/). If the buildpack is using a nonstandard license, then the `uri` key may be specified in lieu of or in addition to `type` to point to the license.
|
||||
|
||||
- **`uri`** _(string, optional)_\
|
||||
A URL or path to the license.
|
||||
|
||||
- **`targets`** _(list, optional)_\
|
||||
A list of targets supported by the buildpack.
|
||||
When no targets are specified, the `os`/`arch` will be inferred from the contents of the `./bin` directory
|
||||
(`./bin/build` implies `linux`/`amd64` and `./bin/build.bat` implies `windows`/`amd64`).
|
||||
For each target, all fields are optional (though at least one should be provided).
|
||||
_Cannot be used in conjunction with `order` list._
|
||||
|
||||
- **`os`** _(string, optional)_\
|
||||
The supported operating system name.
|
||||
|
||||
- **`arch`** _(string, optional)_\
|
||||
The supported architecture.
|
||||
|
||||
- **`variant`** _(string, optional)_\
|
||||
The supported architecture variant.
|
||||
|
||||
- **`targets.distros`** _(optional)_\
|
||||
A list of supported distributions for the given operating system, architecture, and architecture variant.
|
||||
|
||||
- **`name`** _(string, optional)_\
|
||||
The supported operating system distribution name.
|
||||
|
||||
- **`version`** _(string, optional)_\
|
||||
The supported operating system distribution version.
|
||||
|
||||
- **`stacks`** _(list, deprecated, optional)_\
|
||||
A list of stacks supported by the buildpack.
|
||||
_Cannot be used in conjunction with `order` list._
|
||||
|
||||
- **`id`** _(string, required)_\
|
||||
The id of the supported stack.
|
||||
|
||||
- **`mixins`** _(string list, required)_\
|
||||
A list of mixins required on the stack images.
|
||||
|
||||
- **`order`** _(list, optional)_\
|
||||
A list of buildpack groups for the purpose of creating a [meta-buildpack][meta-buildpack]. This list determines the
|
||||
order in which groups of buildpacks will be tested during detection. _If omitted, `targets` or `stacks` list must be present.
|
||||
Cannot be used in conjunction with `targets` or `stacks` list._
|
||||
|
||||
- **`group`** _(list, required)_\
|
||||
A list of buildpack references.
|
||||
|
||||
- **`id`** _(string, required)_\
|
||||
The identifier of a buildpack being referred to.
|
||||
Buildpacks with the same ID may appear in multiple groups at once but never in the same group.
|
||||
|
||||
- **`version`** _(string, required)_\
|
||||
The version of the buildpack being referred to.
|
||||
|
||||
- **`optional`** _(boolean, optional, default: `false`)_\
|
||||
Whether this buildpack is optional during detection.
|
||||
|
||||
- **`metadata`** _(any, optional)_\
|
||||
Arbitrary data for buildpack.
|
||||
|
||||
## Build Plan
|
||||
The [Build Plan](https://github.com/buildpacks/spec/blob/main/buildpack.md#build-plan-toml) is a document the buildpacks can use to pass information between the [detect](#bindetect) and [build](#bindetect) phases. The build plan is passed (by the lifecycle) as a parameter to the `detect` and `build` binaries of the buildpack.
|
||||
* During the `detect` phase, the buildpack(s) may write something it `requires` or `provides` (or both) into the Build Plan.
|
||||
* During the `build` phase, the buildpack(s) may read the Buildpack Plan (a condensed version of the Build Plan, composed by the lifecycle) to determine what it should do, and refine the Buildpack Plan with more exact metadata (eg: what version dependency it requires).
|
||||
|
||||
A buildpack can `require` or `provide` multiple dependencies, and even multiple groupings of dependencies (using `or` lists). Additionally, multiple buildpacks may `require` or `provide` the same dependency.
|
||||
|
||||
The lifecycle uses the Build Plan as one element in deciding whether or not a particular list of buildpacks is appropriate, by seeing whether all dependencies required can be provided by that list.
|
||||
|
||||
### Example
|
||||
Let's walk through some possible cases a `node-engine` buildpack may consider:
|
||||
|
||||
1. Nothing in the app explicitly calls out that it is needed
|
||||
2. It is explicitly referred to in some configuration file
|
||||
|
||||
We will also consider what a `NPM` and a `JVM` buildpack may do.
|
||||
|
||||
#### 1. No Explicit Request
|
||||
A `node-engine` buildpack is always happy to `provide` the `node` dependency. The build plan it will write may look something like:
|
||||
```
|
||||
[[provides]]
|
||||
name = "node"
|
||||
```
|
||||
> **NOTE:** If this was the only buildpack running, this would fail the `detect` phase. In order to pass, every `provides` must be matched up with a `requires`, whether in the same buildpack or in another buildpack. See the [spec](https://github.com/buildpacks/spec/blob/main/buildpack.md#phase-1-detection) for particulars on how ordering buildpacks can adjust detection results.
|
||||
|
||||
#### 2. One Version Requested
|
||||
During the `detect` phase, the `node-engine` buildpack sees in one configuration file (e.g. a `.nvmrc` file in the app directory) that `node v10.x` is explicitly requested by the application. Seeing that, it may write the below text to the build plan:
|
||||
```
|
||||
[[provides]]
|
||||
name = "node"
|
||||
|
||||
[[requires]]
|
||||
name = "node"
|
||||
version = "10.x"
|
||||
|
||||
[requires.metadata]
|
||||
version-source = ".nvmrc"
|
||||
```
|
||||
|
||||
As always, the buildpack `provides` `node`. In this particular case, a version of `node` (`10.x`) is being requested in a configuration file (`.nvmrc`). The buildpack chooses to add an additional piece of metadata (`version-source`), so that it can understand where that request came from.
|
||||
|
||||
#### NPM Buildpack
|
||||
`NPM` is the default package manager for `node`. A NPM Buildpack may ensure that all the packages for the application are present (by running `npm install`), and perhaps cache those packages as well, to optimize future builds.
|
||||
|
||||
NPM is typically distributed together with node. As a result, a NPM buildpack may require `node`, but not want to `provide` it, trusting that the `node-engine` buildpack will be in charge of `providing` `node`.
|
||||
|
||||
The NPM buildpack could write the following to the build plan, if the buildpack sees that `npm` is necessary (e.g., it sees a `package.json` file in the app directory):
|
||||
```
|
||||
[[requires]]
|
||||
name = "node"
|
||||
```
|
||||
|
||||
If, looking in the `package.json` file, the NPM buildpack sees a specific version of `node` requested in the [engines](https://docs.npmjs.com/files/package.json#engines) field (e.g. `14.1`), it may write the following to the build plan:
|
||||
```
|
||||
[[requires]]
|
||||
name = "node"
|
||||
version = "14.1"
|
||||
|
||||
[requires.metadata]
|
||||
version-source = "package.json"
|
||||
```
|
||||
|
||||
> **NOTE:** As above, if this was the only buildpack running, this would fail the `detect` phase. In order to pass, every `provides` must be matched up with a `requires`, whether in the same buildpack or in another buildpack. See the [spec](https://github.com/buildpacks/spec/blob/main/buildpack.md#phase-1-detection) for particulars on how ordering buildpacks can adjust detection results.
|
||||
|
||||
However, if the NPM Buildpack was run together with the Node Engine buildpack (which `provides` `node`), the lifecycle will see that all requirements are fulfilled, and select that group as the correct set of buildpacks.
|
||||
|
||||
#### Possible JVM Buildpack
|
||||
Java is distributed in two formats - the `jdk` (Java Development Kit), which allows for compilation and running of Java programs, and the `jre` (Java Runtime Environment, which allows for running compiled Java programs). A very naive implementation of the buildpack may have it write several `provides` options to the build plan, detailing everything that it can provide, while later buildpacks would figure out based on the application which options it requires, and would `require` those. In this particular case, we can use the `or` operator to present different possible build plans the buildpack can follow:
|
||||
|
||||
```
|
||||
# option 1 (`jre` and `jdk`)
|
||||
[[provides]]
|
||||
name = "jre"
|
||||
|
||||
[[provides]]
|
||||
name = "jdk"
|
||||
|
||||
# option 2 (or just `jdk`)
|
||||
[[or]]
|
||||
[[or.provides]]
|
||||
name = "jdk"
|
||||
|
||||
# option 3 (or just `jre`)
|
||||
[[or]]
|
||||
[[or.provides]]
|
||||
name = "jre"
|
||||
```
|
||||
|
||||
The buildpack gives three options to the lifecycle:
|
||||
* It can provide a standalone `jre`
|
||||
* It can provide a standalone `jdk`
|
||||
* It can provide both the `jdk` and `jre`
|
||||
|
||||
As with the other buildpacks, this alone will not be sufficient for the lifecycle. However, other buildpacks that follow may `require` certain things. For example, another buildpack may look into the application and, seeing that it is a Java executable, `require` the `jre` in order to run it. When the lifecycle analyzes the results of the detect phase, it will see that there is a buildpack which provides `jre`, and a buildpack that requires `jre`, and will therefore conclude that those options represent a valid set of buildpacks.
|
||||
|
||||
### Schema
|
||||
- **`provides`** _(list, optional)_\
|
||||
A list of dependencies which the buildpack provides.
|
||||
- **`name`** _(string, required)_\
|
||||
The name of the provided dependency.
|
||||
|
||||
- **`requires`** _(list, optional)_\
|
||||
A list of dependencies which the buildpack requires.
|
||||
- **`name`** _(string, required)_\
|
||||
The name of the required dependency.
|
||||
|
||||
- **`version`** _(string, optional)_\
|
||||
The version of the dependency required.
|
||||
|
||||
- **`metadata`** _(object, optional)_\
|
||||
Any additional key-value metadata you wish to store.
|
||||
|
||||
- **`or`** _(array, optional)_\
|
||||
A list of alternate requirements which the buildpack provides/requires. Each `or` array must contain a valid Build Plan (with `provides` and `requires`)
|
||||
|
||||
For more information, see the [Build Plan](https://github.com/buildpacks/spec/blob/main/buildpack.md#buildpack-plan-toml) section of the spec.
|
||||
|
||||
## API Compatibility
|
||||
|
||||
**Given** the buildpack and lifecycle both declare a **Buildpack API version** in format:\
|
||||
`<major>.<minor>`
|
||||
A [buildpack] only ever implements one Buildpack API version at a time.
|
||||
The implemented Buildpack API version can be found in the `buildpack.toml` file in the buildpack's root directory,
|
||||
or in a label on a buildpack package.
|
||||
|
||||
**Then** a buildpack and a lifecycle are considered compatible if all the following conditions are true:
|
||||
A [lifecycle] may (and usually does) support more than one Buildpack API version at a time.
|
||||
The supported Buildpack API version(s) can be found in the `lifecycle.toml` file in a lifecycle tarball,
|
||||
or in a label on the [lifecycle image](https://hub.docker.com/r/buildpacksio/lifecycle).
|
||||
|
||||
- If versions are pre-release, where `<major>` is `0`, then `<minor>`s must match.
|
||||
- If versions are stable, where `<major>` is greater than `0`, then `<minor>` of the buildpack must be less than
|
||||
or equal to that of the lifecycle.
|
||||
- `<major>`s must always match.
|
||||
A lifecycle "supports" a buildpack if they both declare support for the same Buildpack API version in format: `<major>.<minor>`.
|
||||
|
||||
<br />
|
||||
For example,
|
||||
|
||||
| Buildpack _implements_ Buildpack API | Lifecycle _implements_ Buildpack API | Compatible? |
|
||||
| ------------------------------------ | ------------------------------------ | ------------------------------------- |
|
||||
| `0.2` | `0.2` | <span class="text-success">yes</span> |
|
||||
| `1.1` | `1.1` | <span class="text-success">yes</span> |
|
||||
| `1.2` | `1.3` | <span class="text-success">yes</span> |
|
||||
| `0.2` | `0.3` | <span class="text-muted">no</span> |
|
||||
| `0.3` | `0.2` | <span class="text-muted">no</span> |
|
||||
| `1.3` | `1.2` | <span class="text-muted">no</span> |
|
||||
| `1.3` | `2.3` | <span class="text-muted">no</span> |
|
||||
| `2.3` | `1.3` | <span class="text-muted">no</span> |
|
||||
Two buildpacks of different Buildpack API versions can participate in the same build,
|
||||
provided they are both supported by the lifecycle.
|
||||
|
||||
## Further Reading
|
||||
|
||||
|
|
@ -396,4 +29,3 @@ You can read the complete [Buildpack API specification on Github](https://github
|
|||
|
||||
[buildpack]: /docs/for-platform-operators/concepts/buildpack/
|
||||
[lifecycle]: /docs/for-platform-operators/concepts/lifecycle/
|
||||
[meta-buildpack]: /docs/for-platform-operators/concepts/buildpack/#meta-buildpack
|
||||
|
|
|
|||
|
|
@ -7,15 +7,6 @@ subcalendars:
|
|||
# - id: teamup id
|
||||
# - name: human readable name
|
||||
# - color: html color of events on calendar
|
||||
- id: 10287223
|
||||
name: Community
|
||||
color: '#4aaace'
|
||||
- id: 9330130
|
||||
name: Office Hours
|
||||
color: '#2951b9'
|
||||
- id: 9046533
|
||||
name: Sub-Team Syncs
|
||||
color: '#542382'
|
||||
- id: 9046534
|
||||
name: Working Group
|
||||
color: '#d96fbf'
|
||||
|
|
@ -90,7 +90,22 @@
|
|||
<a href="/features">See list of features</a>
|
||||
</div>
|
||||
|
||||
<h2>About the Project</h2>
|
||||
<h2>What We Do</h2>
|
||||
<section class="row">
|
||||
<div class="col-sm">
|
||||
<p>Cloud Native Buildpacks (CNBs) transform your application source code into container images that can run on any
|
||||
cloud. With buildpacks, organizations can concentrate the knowledge of container build best practices within a
|
||||
specialized team, instead of having application developers across the organization individually maintain their
|
||||
own Dockerfiles. This makes it easier to know what is inside application images, enforce security and compliance
|
||||
requirements, and perform upgrades with minimal effort and intervention.</p>
|
||||
<p>The CNB project maintains a set of specifications and tooling that make it possible to write buildpacks
|
||||
and orchestrate them together in a build system.
|
||||
Additionally, community providers such as Google, Heroku, and the Paketo project maintain buildpacks
|
||||
for a wide variety of language families, and you can discover even more by searching the buildpack registry.</p>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<h2>Our Origin Story</h2>
|
||||
<section class="row">
|
||||
<div class="col-sm">
|
||||
<p><strong>Buildpacks</strong> were first conceived by Heroku in 2011. Since then, they have been adopted by Cloud
|
||||
|
|
@ -110,8 +125,8 @@
|
|||
<p>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.</p>
|
||||
</div>
|
||||
</section>
|
||||
</div>
|
||||
</section>
|
||||
</div>
|
||||
|
||||
<div id="get-started" class="container">
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 94 KiB After Width: | Height: | Size: 94 KiB |
|
Before Width: | Height: | Size: 80 KiB After Width: | Height: | Size: 80 KiB |
|
Before Width: | Height: | Size: 99 KiB After Width: | Height: | Size: 99 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 25 KiB |
|
Before Width: | Height: | Size: 120 KiB After Width: | Height: | Size: 120 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
|
@ -22,6 +22,7 @@ const (
|
|||
gendocFrontmatterTemplate = `+++
|
||||
title="%s"
|
||||
no_edit="true"
|
||||
aliases=[ "%s" ]
|
||||
+++
|
||||
<!--more-->
|
||||
`
|
||||
|
|
@ -30,7 +31,9 @@ no_edit="true"
|
|||
var filePrepender = func(filename string) string {
|
||||
name := filepath.Base(filename)
|
||||
name = strings.Replace(name, ".md", "", -1)
|
||||
return fmt.Sprintf(gendocFrontmatterTemplate, strings.Replace(name, "_", " ", -1))
|
||||
presentationName := strings.Replace(name, "_", " ", -1)
|
||||
alias := fmt.Sprintf("/docs/tools/pack/cli/%s", name)
|
||||
return fmt.Sprintf(gendocFrontmatterTemplate, presentationName, alias)
|
||||
}
|
||||
|
||||
var linkHandler = func(name string) string {
|
||||
|
|
@ -52,7 +55,7 @@ func main() {
|
|||
}
|
||||
|
||||
if _, err := os.Stat(filepath.Join(outputPath, indexFile)); os.IsNotExist(err) {
|
||||
if err := ioutil.WriteFile(filepath.Join(outputPath, indexFile), []byte(filePrepender("Pack CLI")), os.ModePerm); err != nil {
|
||||
if err := os.WriteFile(filepath.Join(outputPath, indexFile), []byte(filePrepender("Pack CLI")), os.ModePerm); err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
}
|
||||
|
|
|
|||
251
tools/go.mod
251
tools/go.mod
|
|
@ -5,21 +5,23 @@ go 1.21
|
|||
toolchain go1.21.5
|
||||
|
||||
require (
|
||||
github.com/buildpacks/pack v0.33.1
|
||||
github.com/gohugoio/hugo v0.100.2
|
||||
github.com/buildpacks/pack v0.33.2
|
||||
github.com/gohugoio/hugo v0.123.2
|
||||
github.com/spf13/cobra v1.8.0
|
||||
)
|
||||
|
||||
require (
|
||||
cloud.google.com/go v0.110.8 // indirect
|
||||
cloud.google.com/go/compute v1.23.1 // indirect
|
||||
cloud.google.com/go v0.112.0 // indirect
|
||||
cloud.google.com/go/compute v1.24.0 // indirect
|
||||
cloud.google.com/go/compute/metadata v0.2.3 // indirect
|
||||
cloud.google.com/go/iam v1.1.2 // indirect
|
||||
cloud.google.com/go/storage v1.30.1 // indirect
|
||||
cloud.google.com/go/iam v1.1.6 // indirect
|
||||
cloud.google.com/go/storage v1.38.0 // indirect
|
||||
dario.cat/mergo v1.0.0 // indirect
|
||||
github.com/Azure/azure-pipeline-go v0.2.3 // indirect
|
||||
github.com/Azure/azure-sdk-for-go v68.0.0+incompatible // indirect
|
||||
github.com/Azure/azure-storage-blob-go v0.15.0 // indirect
|
||||
github.com/Azure/azure-sdk-for-go/sdk/azcore v1.9.2 // indirect
|
||||
github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.5.1 // indirect
|
||||
github.com/Azure/azure-sdk-for-go/sdk/internal v1.5.2 // indirect
|
||||
github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v1.3.0 // indirect
|
||||
github.com/Azure/go-ansiterm v0.0.0-20230124172434-306776ec8161 // indirect
|
||||
github.com/Azure/go-autorest v14.2.0+incompatible // indirect
|
||||
github.com/Azure/go-autorest/autorest v0.11.29 // indirect
|
||||
|
|
@ -27,109 +29,122 @@ require (
|
|||
github.com/Azure/go-autorest/autorest/azure/auth v0.5.12 // indirect
|
||||
github.com/Azure/go-autorest/autorest/azure/cli v0.4.6 // indirect
|
||||
github.com/Azure/go-autorest/autorest/date v0.3.0 // indirect
|
||||
github.com/Azure/go-autorest/autorest/to v0.4.0 // indirect
|
||||
github.com/Azure/go-autorest/logger v0.2.1 // indirect
|
||||
github.com/Azure/go-autorest/tracing v0.6.0 // indirect
|
||||
github.com/AzureAD/microsoft-authentication-library-for-go v1.2.2 // indirect
|
||||
github.com/BurntSushi/locker v0.0.0-20171006230638-a6e239ea1c69 // indirect
|
||||
github.com/BurntSushi/toml v1.3.2 // indirect
|
||||
github.com/Masterminds/semver v1.5.0 // indirect
|
||||
github.com/Microsoft/go-winio v0.6.1 // indirect
|
||||
github.com/ProtonMail/go-crypto v0.0.0-20230828082145-3c4c8a2d2371 // indirect
|
||||
github.com/PuerkitoBio/purell v1.1.1 // indirect
|
||||
github.com/PuerkitoBio/urlesc v0.0.0-20170810143723-de5bf2ad4578 // indirect
|
||||
github.com/ProtonMail/go-crypto v1.0.0 // indirect
|
||||
github.com/agext/levenshtein v1.2.3 // indirect
|
||||
github.com/alecthomas/chroma v0.10.0 // indirect
|
||||
github.com/alecthomas/chroma/v2 v2.12.0 // indirect
|
||||
github.com/apex/log v1.9.0 // indirect
|
||||
github.com/armon/go-radix v1.0.0 // indirect
|
||||
github.com/aws/aws-sdk-go v1.44.32 // indirect
|
||||
github.com/aws/aws-sdk-go-v2 v1.21.2 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream v1.4.10 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/config v1.19.0 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/credentials v1.13.43 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/feature/ec2/imds v1.13.13 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/feature/s3/manager v1.11.56 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/internal/configsources v1.1.43 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/internal/endpoints/v2 v2.4.37 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/internal/ini v1.3.45 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/internal/v4a v1.0.22 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/ecr v1.20.2 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/ecrpublic v1.18.2 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding v1.9.11 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/internal/checksum v1.1.25 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/internal/presigned-url v1.9.37 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/internal/s3shared v1.13.24 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/s3 v1.30.6 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/sso v1.15.2 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/ssooidc v1.17.3 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/sts v1.23.2 // indirect
|
||||
github.com/aws/smithy-go v1.15.0 // indirect
|
||||
github.com/awslabs/amazon-ecr-credential-helper/ecr-login v0.0.0-20231003182221-725682229e60 // indirect
|
||||
github.com/armon/go-radix v1.0.1-0.20221118154546-54df44f2176c // indirect
|
||||
github.com/aws/aws-sdk-go v1.50.24 // indirect
|
||||
github.com/aws/aws-sdk-go-v2 v1.25.1 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream v1.6.1 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/config v1.27.3 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/credentials v1.17.3 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/feature/ec2/imds v1.15.1 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/feature/s3/manager v1.16.5 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/internal/configsources v1.3.1 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/internal/endpoints/v2 v2.6.1 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/internal/ini v1.8.0 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/internal/v4a v1.3.1 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/cloudfront v1.35.0 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/ecr v1.27.0 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/ecrpublic v1.23.0 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding v1.11.1 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/internal/checksum v1.3.1 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/internal/presigned-url v1.11.1 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/internal/s3shared v1.17.1 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/s3 v1.51.0 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/sso v1.20.0 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/ssooidc v1.23.0 // indirect
|
||||
github.com/aws/aws-sdk-go-v2/service/sts v1.28.0 // indirect
|
||||
github.com/aws/smithy-go v1.20.1 // indirect
|
||||
github.com/awslabs/amazon-ecr-credential-helper/ecr-login v0.0.0-20240206212017-5795caca6e8e // indirect
|
||||
github.com/beorn7/perks v1.0.1 // indirect
|
||||
github.com/bep/clock v0.3.0 // indirect
|
||||
github.com/bep/clocks v0.5.0 // indirect
|
||||
github.com/bep/debounce v1.2.1 // indirect
|
||||
github.com/bep/gitmap v1.3.0 // indirect
|
||||
github.com/bep/goat v0.5.0 // indirect
|
||||
github.com/bep/godartsass v0.14.0 // indirect
|
||||
github.com/bep/golibsass v1.1.0 // indirect
|
||||
github.com/bep/gowebp v0.1.0 // indirect
|
||||
github.com/bep/overlayfs v0.6.0 // indirect
|
||||
github.com/bep/godartsass v1.2.0 // indirect
|
||||
github.com/bep/godartsass/v2 v2.0.0 // indirect
|
||||
github.com/bep/golibsass v1.1.1 // indirect
|
||||
github.com/bep/gowebp v0.3.0 // indirect
|
||||
github.com/bep/lazycache v0.4.0 // indirect
|
||||
github.com/bep/logg v0.4.0 // indirect
|
||||
github.com/bep/mclib v1.20400.20402 // indirect
|
||||
github.com/bep/overlayfs v0.9.1 // indirect
|
||||
github.com/bep/simplecobra v0.4.0 // indirect
|
||||
github.com/bep/tmc v0.5.1 // indirect
|
||||
github.com/buildpacks/imgutil v0.0.0-20240118145509-e94a1b7de8a9 // indirect
|
||||
github.com/buildpacks/lifecycle v0.18.4 // indirect
|
||||
github.com/buildpacks/imgutil v0.0.0-20240206215312-f8d38e1de03d // indirect
|
||||
github.com/buildpacks/lifecycle v0.18.5 // indirect
|
||||
github.com/cespare/xxhash/v2 v2.2.0 // indirect
|
||||
github.com/chrismellard/docker-credential-acr-env v0.0.0-20230304212654-82a0ddb27589 // indirect
|
||||
github.com/clbanning/mxj/v2 v2.5.6 // indirect
|
||||
github.com/cli/safeexec v1.0.0 // indirect
|
||||
github.com/clbanning/mxj/v2 v2.7.0 // indirect
|
||||
github.com/cli/safeexec v1.0.1 // indirect
|
||||
github.com/cloudflare/circl v1.3.7 // indirect
|
||||
github.com/containerd/containerd v1.7.11 // indirect
|
||||
github.com/containerd/containerd v1.7.13 // indirect
|
||||
github.com/containerd/log v0.1.0 // indirect
|
||||
github.com/containerd/stargz-snapshotter/estargz v0.14.3 // indirect
|
||||
github.com/containerd/stargz-snapshotter/estargz v0.15.1 // indirect
|
||||
github.com/containerd/typeurl v1.0.2 // indirect
|
||||
github.com/cpuguy83/go-md2man/v2 v2.0.3 // indirect
|
||||
github.com/cyphar/filepath-securejoin v0.2.4 // indirect
|
||||
github.com/dimchansky/utfbom v1.1.1 // indirect
|
||||
github.com/disintegration/gift v1.2.1 // indirect
|
||||
github.com/distribution/reference v0.5.0 // indirect
|
||||
github.com/dlclark/regexp2 v1.4.0 // indirect
|
||||
github.com/docker/cli v24.0.7+incompatible // indirect
|
||||
github.com/dlclark/regexp2 v1.10.0 // indirect
|
||||
github.com/docker/cli v25.0.3+incompatible // indirect
|
||||
github.com/docker/distribution v2.8.3+incompatible // indirect
|
||||
github.com/docker/docker v24.0.7+incompatible // indirect
|
||||
github.com/docker/docker-credential-helpers v0.8.0 // indirect
|
||||
github.com/docker/docker v25.0.5+incompatible // indirect
|
||||
github.com/docker/docker-credential-helpers v0.8.1 // indirect
|
||||
github.com/docker/go-connections v0.5.0 // indirect
|
||||
github.com/docker/go-metrics v0.0.1 // indirect
|
||||
github.com/docker/go-units v0.5.0 // indirect
|
||||
github.com/dustin/go-humanize v1.0.1 // indirect
|
||||
github.com/emirpasic/gods v1.18.1 // indirect
|
||||
github.com/evanw/esbuild v0.14.43 // indirect
|
||||
github.com/frankban/quicktest v1.14.4 // indirect
|
||||
github.com/fsnotify/fsnotify v1.6.0 // indirect
|
||||
github.com/evanw/esbuild v0.20.1 // indirect
|
||||
github.com/fatih/color v1.16.0 // indirect
|
||||
github.com/felixge/httpsnoop v1.0.4 // indirect
|
||||
github.com/frankban/quicktest v1.14.6 // indirect
|
||||
github.com/fsnotify/fsnotify v1.7.0 // indirect
|
||||
github.com/gdamore/encoding v1.0.0 // indirect
|
||||
github.com/gdamore/tcell/v2 v2.7.0 // indirect
|
||||
github.com/getkin/kin-openapi v0.96.0 // indirect
|
||||
github.com/gdamore/tcell/v2 v2.7.1 // indirect
|
||||
github.com/getkin/kin-openapi v0.123.0 // indirect
|
||||
github.com/ghodss/yaml v1.0.0 // indirect
|
||||
github.com/go-git/gcfg v1.5.1-0.20230307220236-3a3c6141e376 // indirect
|
||||
github.com/go-git/go-billy/v5 v5.5.0 // indirect
|
||||
github.com/go-git/go-git/v5 v5.11.0 // indirect
|
||||
github.com/go-openapi/jsonpointer v0.19.5 // indirect
|
||||
github.com/go-openapi/swag v0.21.1 // indirect
|
||||
github.com/gobuffalo/flect v0.2.5 // indirect
|
||||
github.com/go-logr/logr v1.4.1 // indirect
|
||||
github.com/go-logr/stdr v1.2.2 // indirect
|
||||
github.com/go-openapi/jsonpointer v0.20.2 // indirect
|
||||
github.com/go-openapi/swag v0.22.9 // indirect
|
||||
github.com/gobuffalo/flect v1.0.2 // indirect
|
||||
github.com/gobwas/glob v0.2.3 // indirect
|
||||
github.com/gogo/protobuf v1.3.2 // indirect
|
||||
github.com/gohugoio/go-i18n/v2 v2.1.3-0.20210430103248-4c28c89f8013 // indirect
|
||||
github.com/gohugoio/go-i18n/v2 v2.1.3-0.20230805085216-e63c13218d0e // indirect
|
||||
github.com/gohugoio/hugo-goldmark-extensions/passthrough v0.1.0 // indirect
|
||||
github.com/gohugoio/locales v0.14.0 // indirect
|
||||
github.com/gohugoio/localescompressed v1.0.1 // indirect
|
||||
github.com/golang-jwt/jwt/v4 v4.5.0 // indirect
|
||||
github.com/golang-jwt/jwt/v5 v5.2.0 // indirect
|
||||
github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect
|
||||
github.com/golang/protobuf v1.5.3 // indirect
|
||||
github.com/google/go-cmp v0.6.0 // indirect
|
||||
github.com/google/go-containerregistry v0.18.0 // indirect
|
||||
github.com/google/s2a-go v0.1.4 // indirect
|
||||
github.com/google/uuid v1.4.0 // indirect
|
||||
github.com/google/wire v0.5.0 // indirect
|
||||
github.com/googleapis/enterprise-certificate-proxy v0.2.4 // indirect
|
||||
github.com/googleapis/gax-go/v2 v2.12.0 // indirect
|
||||
github.com/gorilla/mux v1.8.0 // indirect
|
||||
github.com/gorilla/websocket v1.5.0 // indirect
|
||||
github.com/hairyhenderson/go-codeowners v0.2.3-0.20201026200250-cdc7c0759690 // indirect
|
||||
github.com/google/go-containerregistry v0.19.0 // indirect
|
||||
github.com/google/s2a-go v0.1.7 // indirect
|
||||
github.com/google/uuid v1.6.0 // indirect
|
||||
github.com/google/wire v0.6.0 // indirect
|
||||
github.com/googleapis/enterprise-certificate-proxy v0.3.2 // indirect
|
||||
github.com/googleapis/gax-go/v2 v2.12.1 // indirect
|
||||
github.com/gorilla/mux v1.8.1 // indirect
|
||||
github.com/gorilla/websocket v1.5.1 // indirect
|
||||
github.com/hairyhenderson/go-codeowners v0.4.0 // indirect
|
||||
github.com/hashicorp/golang-lru/v2 v2.0.7 // indirect
|
||||
github.com/heroku/color v0.0.6 // indirect
|
||||
github.com/inconshreveable/mousetrap v1.1.0 // indirect
|
||||
github.com/invopop/yaml v0.2.0 // indirect
|
||||
|
|
@ -138,86 +153,100 @@ require (
|
|||
github.com/jmespath/go-jmespath v0.4.0 // indirect
|
||||
github.com/josharian/intern v1.0.0 // indirect
|
||||
github.com/kevinburke/ssh_config v1.2.0 // indirect
|
||||
github.com/klauspost/compress v1.17.1 // indirect
|
||||
github.com/klauspost/compress v1.17.7 // indirect
|
||||
github.com/kr/pretty v0.3.1 // indirect
|
||||
github.com/kr/text v0.2.0 // indirect
|
||||
github.com/kyokomi/emoji/v2 v2.2.9 // indirect
|
||||
github.com/kylelemons/godebug v1.1.0 // indirect
|
||||
github.com/kyokomi/emoji/v2 v2.2.12 // indirect
|
||||
github.com/lucasb-eyer/go-colorful v1.2.0 // indirect
|
||||
github.com/magefile/mage v1.14.0 // indirect
|
||||
github.com/magefile/mage v1.15.0 // indirect
|
||||
github.com/mailru/easyjson v0.7.7 // indirect
|
||||
github.com/makeworld-the-better-one/dither/v2 v2.4.0 // indirect
|
||||
github.com/marekm4/color-extractor v1.2.1 // indirect
|
||||
github.com/mattn/go-colorable v0.1.13 // indirect
|
||||
github.com/mattn/go-ieproxy v0.0.7 // indirect
|
||||
github.com/mattn/go-isatty v0.0.20 // indirect
|
||||
github.com/mattn/go-runewidth v0.0.15 // indirect
|
||||
github.com/matttproud/golang_protobuf_extensions v1.0.4 // indirect
|
||||
github.com/mitchellh/go-homedir v1.1.0 // indirect
|
||||
github.com/mitchellh/hashstructure v1.1.0 // indirect
|
||||
github.com/mitchellh/ioprogress v0.0.0-20180201004757-6a23b12fa88e // indirect
|
||||
github.com/mitchellh/mapstructure v1.5.0 // indirect
|
||||
github.com/moby/buildkit v0.12.2 // indirect
|
||||
github.com/mitchellh/mapstructure v1.5.1-0.20231216201459-8508981c8b6c // indirect
|
||||
github.com/moby/buildkit v0.12.5 // indirect
|
||||
github.com/moby/patternmatcher v0.6.0 // indirect
|
||||
github.com/moby/sys/sequential v0.5.0 // indirect
|
||||
github.com/moby/sys/user v0.1.0 // indirect
|
||||
github.com/moby/term v0.5.0 // indirect
|
||||
github.com/mohae/deepcopy v0.0.0-20170929034955-c48cc78d4826 // indirect
|
||||
github.com/morikuni/aec v1.0.0 // indirect
|
||||
github.com/muesli/smartcrop v0.3.0 // indirect
|
||||
github.com/niklasfasching/go-org v1.6.5 // indirect
|
||||
github.com/niklasfasching/go-org v1.7.0 // indirect
|
||||
github.com/olekukonko/tablewriter v0.0.5 // indirect
|
||||
github.com/opencontainers/go-digest v1.0.0 // indirect
|
||||
github.com/opencontainers/image-spec v1.1.0-rc5 // indirect
|
||||
github.com/opencontainers/runc v1.1.12 // indirect
|
||||
github.com/opencontainers/image-spec v1.1.0 // indirect
|
||||
github.com/opencontainers/selinux v1.11.0 // indirect
|
||||
github.com/pbnjay/memory v0.0.0-20210728143218-7b4eea64cf58 // indirect
|
||||
github.com/pelletier/go-toml v1.9.5 // indirect
|
||||
github.com/pelletier/go-toml/v2 v2.0.2 // indirect
|
||||
github.com/pelletier/go-toml/v2 v2.1.1 // indirect
|
||||
github.com/perimeterx/marshmallow v1.1.5 // indirect
|
||||
github.com/pjbgf/sha1cd v0.3.0 // indirect
|
||||
github.com/pkg/browser v0.0.0-20240102092130-5ac0b6a4141c // indirect
|
||||
github.com/pkg/errors v0.9.1 // indirect
|
||||
github.com/prometheus/client_golang v1.17.0 // indirect
|
||||
github.com/prometheus/client_model v0.5.0 // indirect
|
||||
github.com/prometheus/common v0.44.0 // indirect
|
||||
github.com/prometheus/client_golang v1.18.0 // indirect
|
||||
github.com/prometheus/client_model v0.6.0 // indirect
|
||||
github.com/prometheus/common v0.48.0 // indirect
|
||||
github.com/prometheus/procfs v0.12.0 // indirect
|
||||
github.com/rivo/tview v0.0.0-20220610163003-691f46d6f500 // indirect
|
||||
github.com/rivo/uniseg v0.4.3 // indirect
|
||||
github.com/rogpeppe/go-internal v1.11.0 // indirect
|
||||
github.com/rivo/tview v0.0.0-20240204151237-861aa94d61c8 // indirect
|
||||
github.com/rivo/uniseg v0.4.7 // indirect
|
||||
github.com/rogpeppe/go-internal v1.12.0 // indirect
|
||||
github.com/russross/blackfriday/v2 v2.1.0 // indirect
|
||||
github.com/rwcarlsen/goexif v0.0.0-20190401172101-9e8deecbddbd // indirect
|
||||
github.com/sabhiram/go-gitignore v0.0.0-20210923224102-525f6e181f06 // indirect
|
||||
github.com/sanity-io/litter v1.5.5 // indirect
|
||||
github.com/sergi/go-diff v1.2.0 // indirect
|
||||
github.com/sergi/go-diff v1.3.1 // indirect
|
||||
github.com/sirupsen/logrus v1.9.3 // indirect
|
||||
github.com/skeema/knownhosts v1.2.1 // indirect
|
||||
github.com/spf13/afero v1.10.0 // indirect
|
||||
github.com/spf13/cast v1.5.0 // indirect
|
||||
github.com/spf13/fsync v0.9.0 // indirect
|
||||
github.com/spf13/jwalterweatherman v1.1.0 // indirect
|
||||
github.com/spf13/afero v1.11.0 // indirect
|
||||
github.com/spf13/cast v1.6.0 // indirect
|
||||
github.com/spf13/fsync v0.10.0 // indirect
|
||||
github.com/spf13/pflag v1.0.5 // indirect
|
||||
github.com/tdewolff/minify/v2 v2.11.9 // indirect
|
||||
github.com/tdewolff/parse/v2 v2.6.0 // indirect
|
||||
github.com/tdewolff/minify/v2 v2.20.17 // indirect
|
||||
github.com/tdewolff/parse/v2 v2.7.12 // indirect
|
||||
github.com/vbatts/tar-split v0.11.5 // indirect
|
||||
github.com/xanzy/ssh-agent v0.3.3 // indirect
|
||||
github.com/yuin/goldmark v1.4.13 // indirect
|
||||
github.com/yuin/goldmark v1.7.0 // indirect
|
||||
github.com/yuin/goldmark-emoji v1.0.2 // indirect
|
||||
go.opencensus.io v0.24.0 // indirect
|
||||
go.uber.org/atomic v1.9.0 // indirect
|
||||
gocloud.dev v0.25.0 // indirect
|
||||
golang.org/x/crypto v0.18.0 // indirect
|
||||
golang.org/x/image v0.0.0-20220601225756-64ec528b34cd // indirect
|
||||
golang.org/x/mod v0.14.0 // indirect
|
||||
golang.org/x/net v0.20.0 // indirect
|
||||
golang.org/x/oauth2 v0.16.0 // indirect
|
||||
go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.48.0 // indirect
|
||||
go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.48.0 // indirect
|
||||
go.opentelemetry.io/otel v1.23.1 // indirect
|
||||
go.opentelemetry.io/otel/metric v1.23.1 // indirect
|
||||
go.opentelemetry.io/otel/trace v1.23.1 // indirect
|
||||
go.uber.org/automaxprocs v1.5.3 // indirect
|
||||
gocloud.dev v0.36.0 // indirect
|
||||
golang.org/x/crypto v0.19.0 // indirect
|
||||
golang.org/x/exp v0.0.0-20240222234643-814bf88cf225 // indirect
|
||||
golang.org/x/image v0.15.0 // indirect
|
||||
golang.org/x/mod v0.15.0 // indirect
|
||||
golang.org/x/net v0.21.0 // indirect
|
||||
golang.org/x/oauth2 v0.17.0 // indirect
|
||||
golang.org/x/sync v0.6.0 // indirect
|
||||
golang.org/x/sys v0.16.0 // indirect
|
||||
golang.org/x/term v0.16.0 // indirect
|
||||
golang.org/x/sys v0.17.0 // indirect
|
||||
golang.org/x/term v0.17.0 // indirect
|
||||
golang.org/x/text v0.14.0 // indirect
|
||||
golang.org/x/tools v0.16.1 // indirect
|
||||
golang.org/x/xerrors v0.0.0-20220907171357-04be3eba64a2 // indirect
|
||||
google.golang.org/api v0.128.0 // indirect
|
||||
golang.org/x/time v0.5.0 // indirect
|
||||
golang.org/x/tools v0.18.0 // indirect
|
||||
golang.org/x/xerrors v0.0.0-20231012003039-104605ab7028 // indirect
|
||||
google.golang.org/api v0.166.0 // indirect
|
||||
google.golang.org/appengine v1.6.8 // indirect
|
||||
google.golang.org/genproto v0.0.0-20231012201019-e917dd12ba7a // indirect
|
||||
google.golang.org/genproto/googleapis/api v0.0.0-20231002182017-d307bd883b97 // indirect
|
||||
google.golang.org/genproto/googleapis/rpc v0.0.0-20231016165738-49dd2c1f3d0b // indirect
|
||||
google.golang.org/grpc v1.58.3 // indirect
|
||||
google.golang.org/protobuf v1.31.0 // indirect
|
||||
google.golang.org/genproto v0.0.0-20240221002015-b0ce06bbee7c // indirect
|
||||
google.golang.org/genproto/googleapis/api v0.0.0-20240221002015-b0ce06bbee7c // indirect
|
||||
google.golang.org/genproto/googleapis/rpc v0.0.0-20240221002015-b0ce06bbee7c // indirect
|
||||
google.golang.org/grpc v1.62.0 // indirect
|
||||
google.golang.org/protobuf v1.32.0 // indirect
|
||||
gopkg.in/warnings.v0 v0.1.2 // indirect
|
||||
gopkg.in/yaml.v2 v2.4.0 // indirect
|
||||
gopkg.in/yaml.v3 v3.0.1 // indirect
|
||||
howett.net/plist v1.0.1 // indirect
|
||||
software.sslmate.com/src/go-pkcs12 v0.4.0 // indirect
|
||||
)
|
||||
|
||||
replace github.com/moby/buildkit => github.com/moby/buildkit v0.11.6
|
||||
|
|
|
|||
1008
tools/go.sum
1008
tools/go.sum
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue