Merge branch 'main' into dependabot/github_actions/peaceiris/actions-…

…gh-pages-4

.github/workflows/main.yml

@@ -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.4
+        uses: buildpacks/github-actions/setup-pack@v5.7.0
         with:
           pack-version: '0.31.0'
       - name: Test

content/docs/.common/concepts/composite-buildpack.md

@@ -3,7 +3,7 @@ title="What is a composite buildpack?"
 weight=99
 +++
 
-A composite buildpack, also sometimes called a "meta-buildpack",
+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.
 

content/docs/_index.md

@@ -4,24 +4,30 @@ weight=1
 summary="Get started with Cloud Native Buildpacks."
 +++
 
-## Talks
+## Welcome
 
-{{< talks >}}
+Cloud Native Buildpacks (CNBs) transform your application source code into [container images](https://github.com/opencontainers/image-spec/blob/main/spec.md) 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.
+
+The CNB project was initiated by Pivotal and Heroku in January 2018 and joined the Cloud Native Computing Foundation (CNCF) as an Apache-2.0 licensed project in October 2018. It is currently an incubating project within the CNCF.
 
 ---
 
 ## Tutorials
 
 * [An App’s Brief Journey from Source to Image](/docs/app-journey/) - An easy-to-follow introduction to Cloud Native Buildpacks using `pack`, a command line tool for Cloud Native Buildpacks.
-* [Creating a Cloud Native Buildpack](/docs/for-buildpack-authors/tutorials/basic-buildpack) - Tutorial walking through the creation of a simple Ruby buildpack.
+* [How to write a basic buildpack](/docs/for-buildpack-authors/tutorials/basic-buildpack) - A tutorial walking through the creation of an example NodeJS buildpack.
+
+---
 
 ## Going deeper
 
 See how-to guides, concepts, and tutorials tailored to specific personas:
 
-*  [App Developers](/docs/for-app-developers/)
-*  [Buildpack Authors](/docs/for-buildpack-authors/)
-*  [Operators](/docs/for-platform-operators/)
+* [App Developers](/docs/for-app-developers/)
+* [Buildpack Authors](/docs/for-buildpack-authors/)
+* [Operators](/docs/for-platform-operators/)
 
 ## [Tools](/docs/for-platform-operators/)
 
@@ -31,6 +37,8 @@ See how-to guides, concepts, and tutorials tailored to specific personas:
 * **[Pack](/docs/for-platform-operators/how-to/integrate-ci/pack)** - {{< summary "/docs/for-platform-operators/how-to/integrate-ci/pack" >}}
 * **[Tekton](/docs/for-platform-operators/how-to/integrate-ci/tekton)** - {{< summary "/docs/for-platform-operators/how-to/integrate-ci/tekton" >}}
 
+---
+
 ## [Reference](/docs/reference/)
 
 Reference documents for various key aspects of the project.
@@ -40,18 +48,36 @@ Reference documents for various key aspects of the project.
 
 ---
 
-# Community and Support
+## Talks
+
+We love talks to share the latest development updates, explain buildpacks basics and more, receive feedback and questions, and get to know other members of the community.
+
+### Conference Talks
+
+Check out some of our most recent and exciting conference talks below. More talks are available in our [Conference Talks Playlist](https://www.youtube.com/playlist?list=PL1p8pquzNvRqz3v7Q-OA7wldIxLCNFHcC) on YouTube.
+
+{{< talks >}}
+
+If you are interested in giving a talk about buildpacks, the linked slides may provide a useful starting point. Please feel free to reach out in Slack if you'd like input or help from the CNB team!
+
+### Meetings
+
+Feel free to look through the archive of previous community meetings in our [Working Group Playlist](https://www.youtube.com/playlist?list=PL1p8pquzNvRpDbbgZ0db0MRA-W5_w0G1U) on YouTube. If you would like to attend a Working Group meeting, check out our [community](/community/) page.
+
+---
+
+## Community and Support
 
 Cloud Native Buildpacks is an incubating project in the CNCF. We welcome contribution from the community. Here you will find helpful information for interacting with the core team and contributing to the project.
 
-## Community
+### Community
 
 The best place to contact the Cloud Native Buildpack team is on the [CNCF Slack](https://slack.cncf.io/) in the #buildpacks or [mailing list](https://lists.cncf.io/g/cncf-buildpacks).
 
-## Contributor's Guide
+### Contributor's Guide
 
 Find out the various ways that _you_ can contribute to the Cloud Native Buildpacks project using our [contributor's guide](https://github.com/buildpacks/community/blob/main/contributors/guide.md).
 
-## Project Roadmap
+### Project Roadmap
 
 This is a community driven project and our roadmap is publicly available on our [Github page](https://github.com/buildpacks/community/blob/main/ROADMAP.md). We encourage you to contribute with feature requests.

content/docs/for-app-developers/how-to/special-cases/build-for-arm.md

@@ -9,94 +9,51 @@ weight=1
 
 <!--more-->
 
-As of today, there are no known released CNB builder images that support building ARM application images. 
+Building for the ARM architecture is now easier than ever! The `heroku/builder:24` builder supports both AMD64 and ARM64 architectures, and includes
+multi-arch Go, Java, Node.js, PHP, Python, Ruby and Scala buildpacks. You can read more about Heroku's [Cloud Native Buildpacks here][heroku-buildpacks].
 
-Users can create their own ARM64 builder image by following [this guide][this guide].
+### 1. Clone the [samples][samples] repository
 
-In the following tutorial, we will be performing a build "manually", in that we will be performing a build by invoking the lifecycle directly.
-
-### 1. Prepare your working directory
-
-On your Linux ARM machine with a [docker][docker] daemon installed, prepare the following directory tree structure.
-
-```bash
-tree ~/workspace/
-~/workspace/
-├── buildpacks
-│   └── samples_hello-world
-└── platform
 ```
-
-In addition, clone the [samples][samples] repository which will contain the application source code.
-
-```bash
 # clone the repo
-git clone https://github.com/buildpacks/samples ~/workspace/samples
+git clone https://github.com/buildpacks/samples
 ```
+<!--+- "{{execute}}"+-->
 
-### 2. Prepare the assets
-
-Now we need to prepare assets that will be used during the build process.
-
-First we download and extract the [lifecycle][lifecycle] release, compiled for ARM. Make sure to replace `<RELEASE-VERSION>` with a valid release version.
+### 2. Build the app
 
-```bash
-# change to destination directory
-cd ~/workspace
-
-# download and extract lifecycle
-curl -L https://github.com/buildpacks/lifecycle/releases/download/v<RELEASE-VERSION>/lifecycle-v<RELEASE-VERSION>+linux.arm64.tgz | tar xzf -
+If you're using an ARM64 computer (such as an Apple Silicon Mac, or an AWS Graviton instance), you can build an ARM64 OCI image with [pack][pack] simply by setting your builder to `heroku/builder:24`:
 ```
-
-Next we make sure that our buildpack directory is structured in a way that the lifecycle will expect.
-
-```bash
-# copy hello-world buildpack
-cp -R ~/workspace/samples/buildpacks/hello-world ~/workspace/buildpacks/samples_hello-world/0.0.1
+pack build java-maven-sample --path samples/apps/java-maven/ --builder heroku/builder:24
 ```
+<!--+- "{{execute}}"+-->
 
-And finally we write the `order.toml` file that references the hello-world buildpack.
+By default, `pack` uses the current architecture for multi-arch builders like `heroku/builder:24`, so an AMD64 image will be built on AMD64 systems.
 
-```bash
-cat > ~/workspace/order.toml <EOF
-[[order]]
-[[order.group]]
-id = "samples/hello-world"
-version = "0.0.1"
-optional = false
-EOF
+If you want to build an ARM64 image from a different host architecture, use the `--platform` parameter:
 ```
+pack build java-maven-sample --path samples/apps/java-maven/ --builder heroku/builder:24 --platform linux/arm64
+```
+<!--+- "{{execute}}"+-->
 
-### 3. Build your app
+> **TIP:** If you don't want to keep specifying a builder every time you build, you can set it as your default
+> builder by running `pack config default-builder <BUILDER>` for example `pack config default-builder heroku/builder:24`
+<!--+- "{{execute}}"+-->
 
-Now we can build our app. For this example we will be using the docker CLI to invoke the lifecycle directly.
+### 3. Run it
 
-```bash
-# invoke the lifecycle
-docker run --rm \
-  --mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
-  --volume ~/workspace/lifecycle:/cnb/lifecycle \
-  --volume ~/workspace/buildpacks:/cnb/buildpacks \
-  --volume ~/workspace/samples/apps/bash-script:/workspace \
-  --volume ~/workspace/platform:/platform \
-  --mount type=bind,source=~/workspace/order.toml,target=/cnb/order.toml \
-  --env CNB_PLATFORM_API=0.7 \
-  ubuntu:jammy \
-  /cnb/lifecycle/creator -log-level debug -daemon -run-image ubuntu:jammy hello-arm64
 ```
-
-### 4. Run it
-
-```bash
-docker run --rm hello-arm64
+docker run --rm -p 8080:8080 java-maven-sample
 ```
+<!--+- "{{execute}}"+-->
 
 **Congratulations!**
 
-The app image should now be built and stored on the docker daemon. You may perform `docker images` to verify.
+<!--+- if false+-->
+The app should now be running and accessible via [localhost:8080](http://localhost:8080).
+<!--+end+-->
 
 [pack]: https://github.com/buildpacks/pack
 [docker]: https://docs.docker.com
 [samples]: https://github.com/buildpacks/samples
-[lifecycle]: https://github.com/buildpacks/lifecycle
-[this guide]: https://github.com/dmikusa-pivotal/paketo-arm64
+[heroku-buildpacks]: https://github.com/heroku/buildpacks

content/docs/for-buildpack-authors/concepts/buildpack-group.md

@@ -15,26 +15,27 @@ Buildpack groups allow you to connect multiple modular buildpacks together, maki
 
 For example, you might have a buildpack that installs Java and a buildpack that uses Maven to build your application. These two buildpacks can be combined into a group to implement higher-level functionality, specifically that the first one will install Java and the second will use Java to run Maven, which is a Java build tool.
 
-Because you can have many buildpack groups in a [builder][builder] or [meta-buildpack][meta-buildpack] and you can reuse buildpacks, you could have a second buildpack group that reuses the buildpack to provide Java but uses a third buildpack that provides Gradle to build your application. By doing this, you can create additional high-level functionality without having duplication.
+Because you can have many buildpack groups in a [builder][builder] or [composite buildpack][composite buildpack] (sometimes referred to as a "meta buildpack"),
+and you can reuse buildpacks, you could have a second buildpack group that reuses the buildpack to provide Java but uses a third buildpack that provides Gradle to build your application. By doing this, you can create additional high-level functionality without having duplication.
 
 ## Anatomy of a buildpack group
 
 A [buildpack group][buildpack-group] is a list of buildpack entries defined in the order in which they will run.
 
-A buildpack entry is identified by an id and a version. It may also be marked as optional. While you may have one or more buildpacks in a buildpack group, you may have one or more buildpack groups in a builder or meta-buildpack.
+A buildpack entry is identified by an id and a version. It may also be marked as optional. While you may have one or more buildpacks in a buildpack group, you may have one or more buildpack groups in a builder or composite buildpack.
 
 ## Detection with buildpack groups
 
-A [builder][builder] or [meta-buildpack][meta-buildpack] may contain multiple buildpack groups. When the lifecycle executes the detection process, it will process each buildpack group it finds in the order that the groups are specified. For each buildpack group, the lifecycle will execute the detect phase of all buildpacks in that group (these can be executed in parallel) and aggregate the results. The lifecycle will select the first buildpack group by order where all of the non-optional buildpacks in that group pass detection.
+A [builder][builder] or [composite buildpack][composite buildpack] may contain multiple buildpack groups. When the lifecycle executes the detection process, it will process each buildpack group it finds in the order that the groups are specified. For each buildpack group, the lifecycle will execute the detect phase of all buildpacks in that group (these can be executed in parallel) and aggregate the results. The lifecycle will select the first buildpack group by order where all of the non-optional buildpacks in that group pass detection.
 
 For example, if a builder has buildpack groups A, B and C. The lifecycle will run detection against A. If all of the non-optional buildpacks in that group pass detection, then it will select A. In that case, B and C will not be processed. If A has any failing non-optional buildpacks, then the lifecycle will move on to process buildpack group B. If B has any failing non-optional buildpacks, then the lifecycle will move on to process buildpack group C. If C fails, then the entire detection process will fail.
 
-If a buildpack group contains meta-buildpacks, which in turn may contain more buildpack groups those are expanded using [the order resolution rules][order-resolution] such that each buildpack group in the meta-buildpack is tried with the other buildpacks in the containing buildpack group.
+If a buildpack group contains composite buildpacks, which in turn may contain more buildpack groups those are expanded using [the order resolution rules][order-resolution] such that each buildpack group in the composite buildpack is tried with the other buildpacks in the containing buildpack group.
 
 For example:
 
 - the builder has a buildpack group A that contains buildpacks X, Y and Z
-- Y is a meta-buildpack containing buildpack groups B and C
+- Y is a composite buildpack containing buildpack groups B and C
 - buildpack group B contains buildpacks T and U
 - buildpack group C contains buildpacks V and W
 
@@ -43,7 +44,7 @@ The lifecycle will expand this into the following buildpack groups:
 - X, T, U, Z
 - X, V, W, Z
 
-Y is not included because meta-buildpacks only provide groups, they do not participate in the build process or contain build/detect binaries.
+Y is not included because composite buildpacks only provide groups, they do not participate in the build process or contain build/detect binaries.
 
 The [order resolution rules in the buildpacks spec][order-resolution] contains additional examples that illustrate more complex scenarios.
 
@@ -57,4 +58,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/composite-buildpack
+[composite buildpack]: /docs/for-platform-operators/concepts/composite-buildpack

content/docs/for-buildpack-authors/concepts/lifecycle-phases.md

@@ -19,15 +19,15 @@ In the example we run `pack` on the NodeJS application to produce an application
 
 ## NodeJS buildpack
 
-The example NodeJS buildpack is a meta-buildpack.  It is composed of
+The example NodeJS buildpack is a composite buildpack (sometimes referred to as a "meta buildpack").  It is composed of
 
 * `node-engine` buildpack that provides the `node` and `npm` binaries,
 * `yarn` buildpack that provides the `yarn` binary,
 * `yarn-install` and `npm-install` buildpacks that install dependencies using either `yarn` or `npm`,
 * `yarn-start` and `npm-start` buildpacks that configure the entrypoint to the application image,
 * `procfile` a buildpack that allows developers to provide a [Heroku-style](https://devcenter.heroku.com/articles/procfile#procfile-format) entrypoint for the image.
 
-The `nodejs` buildpack itself is a meta-buildpack which defines two **order groups**.  Here we represent the order groups visually:
+The `nodejs` buildpack itself is a composite buildpack which defines two **order groups**.  Here we represent the order groups visually:
 
 ![nodejs order groups](/images/order-groups.svg)
 
@@ -79,7 +79,7 @@ The dependencies are provided using the mechanism an NodeJS developer expects.
 
 Finally, we describe the container entrypoint using a script in the `package.json`.  The script must be named `start` according to NodeJS convention.   Here we see that the entrypoint should run the provided `node index.js` command.
 
-We build our application using the default builder and specify to only use the `nodejs` meta-buildpack in the build.  The restriction to use only the `nodejs` meta-buildpack simplifies the explanation as that buildpack provides only two order groups.
+We build our application using the default builder and specify to only use the `nodejs` composite buildpack in the build.  The restriction to use only the `nodejs` composite buildpack simplifies the explanation as that buildpack provides only two order groups.
 
 <asciinema-player
   idle-time-limit="0.5s"
@@ -388,4 +388,4 @@ Our NodeJS example image requires an entrypoint called `web`.  The `web` entrypo
 
 ## Summary
 
-We have taken a detailed look at how buildpacks are used to build a sample application.  The meta-buildpack contains two order groups and we have seen examples of how an order group is resolved.  In addition we have looked at the contributions that a buildpack makes to the build plan and considered how these are resolved into a buildpack plan to be provided to the build phase of specific buildpacks.  Finally, we have briefly considered how the analyze and restore phases can allow advanced caching strategies.
+We have taken a detailed look at how buildpacks are used to build a sample application.  The composite buildpack contains two order groups and we have seen examples of how an order group is resolved.  In addition we have looked at the contributions that a buildpack makes to the build plan and considered how these are resolved into a buildpack plan to be provided to the build phase of specific buildpacks.  Finally, we have briefly considered how the analyze and restore phases can allow advanced caching strategies.