Merge branch 'main' into dependabot/github_actions/actions/setup-go-4

RELEASE.md

@@ -15,15 +15,15 @@ Some use cases in which this may be desired...
 ### Process
 
 1. A milestone in the following format is created: `<component(s)>/<version>` <sup>*</sup>
-1. Issues are created and tagged with appropriete milestone.
+1. Issues are created and tagged with appropriate milestone.
 1. A release branch in the following format is created off of `main`: `release/<component(s)>/<version>` <sup>*</sup>
 1. As changes are completed, PRs would target the release branch and merged using the same guidelines as merging to `main`.
-1. Once all issues and/or the associated component release is shipped, the release branch is merged into `main` by subteam maintainers.
+1. Once all issues and/or the associated component release is shipped, the release branch is merged into `main` by sub-team maintainers.
 
 _* may require a [project contributor or maintainer](https://github.com/buildpacks/community/blob/main/TEAMS.md) intervention._
 
 
-##### Example Namings
+##### Example Naming
 
 Branches:
 
@@ -42,7 +42,7 @@ Milestones:
 
 ##### Example Workflow
 
-Let's imagine `pack` is releasing version `1.2.3`. It is known that there will be a decent amount of changes to a few guides and we'd like to seperate the entire set of changes per guide. The steps that would be taken are as follows:
+Let's imagine `pack` is releasing version `1.2.3`. It is known that there will be a decent amount of changes to a few guides and we'd like to separate the entire set of changes per guide. The steps that would be taken are as follows:
 
 1. A milestone `pack/1.2.3` would be created.
 1. Issues for the necessary changes would be tagged with milestone `pack/1.2.3`.

content/community.md

@@ -15,7 +15,7 @@ Partake in one or many of our following public events:
 
 #### How can I start contributing?
 
-If you are new to the project, the first thing you should do is gain some understanding of the project. This normaly entails doing the following:
+If you are new to the project, the first thing you should do is gain some understanding of the project. This normally entails doing the following:
 
 1. Watch a few [talks (videos)][talks].
 2. Next, run through some [tutorials][tutorials].
@@ -30,7 +30,7 @@ If you didn't find anything you'd like to improve while going through the tutori
 | [`lifecycle`][lifecycle] | Go, Docker             | Executables that implement the main [specifications][spec] and are used by [platforms][platforms] such as `pack`.
 | [`docs`][docs]           | Hugo, HTML, JavaScript | Main website and documentation.
 
-> Dependending our your depth of understading or desires some components may be more ideal than others.
+> Depending our your depth of understanding or desires some components may be more ideal than others.
 
 [talks]: /docs/#talks
 [tutorials]: /docs/#tutorials

content/docs/app-developer-guide/specify-buildpacks.md

@@ -102,7 +102,7 @@ A buildpack located in a CNB Registry
 - `urn:cnb:registry:bp-id@bp.version`
 
 <small><sup>†</sup> Directory buildpacks are not currently supported on Windows.</small><br />
-<small><sup>‡</sup> Version may be omited if there is only one buildpack in the builder matching the `id`.</small>
+<small><sup>‡</sup> Version may be omitted if there is only one buildpack in the builder matching the `id`.</small>
 
 [project-toml]: /docs/app-developer-guide/using-project-descriptor/
 [samples]: https://github.com/buildpacks/samples

content/docs/app-developer-guide/using-http-proxy.md

@@ -25,7 +25,7 @@ The `pack` tool uses the Docker daemon to manage the local image registry on you
 
 
 ### Docker Desktop (Windows and MacOS)
-Docker's documetation states "Docker Desktop lets you configure HTTP/HTTPS Proxy Settings and automatically propagates these to Docker".  Set the system proxy using the [MacOS documentation](https://support.apple.com/en-gb/guide/mac-help/mchlp2591/mac) or [Windows documentation](https://www.dummies.com/computers/operating-systems/windows-10/how-to-set-up-a-proxy-in-windows-10/).  The system proxy settings will be used by Docker Desktop.
+Docker's documentation states "Docker Desktop lets you configure HTTP/HTTPS Proxy Settings and automatically propagates these to Docker".  Set the system proxy using the [MacOS documentation](https://support.apple.com/en-gb/guide/mac-help/mchlp2591/mac) or [Windows documentation](https://www.dummies.com/computers/operating-systems/windows-10/how-to-set-up-a-proxy-in-windows-10/).  The system proxy settings will be used by Docker Desktop.
 
 ### Linux
 The Docker project documents [how to configure configure the HTTP/HTTPS proxy](https://docs.docker.com/config/daemon/systemd/#httphttps-proxy) settings for the Docker daemon on Linux.  You should configure the `HTTP_PROXY` and `HTTPS_PROXY` environment variables as part of the Docker daemon startup.

content/docs/app-developer-guide/using-inline-buildpacks.md

@@ -4,9 +4,9 @@ weight=7
 summary="Learn how to create an ephemeral buildpack to customize your build."
 +++
 
-You can supplement your app's build proces with custom scripts by creating an _inline buildpack_. An inline buildpack is an ephemeral buildpack that's defined in your [project descriptor][project-toml] (i.e. `project.toml`). You can include a script to run as part of the build without setting up all the files and directories that are required for a complete buildpack.
+You can supplement your app's build process with custom scripts by creating an _inline buildpack_. An inline buildpack is an ephemeral buildpack that's defined in your [project descriptor][project-toml] (i.e. `project.toml`). You can include a script to run as part of the build without setting up all the files and directories that are required for a complete buildpack.
 
-Inline buildpacks are defined as an entry in the `[[build.buildpacks]]` table of the project descriptor by inlcuding an `inline` script in the `[build.buildpacks.script]` table.
+Inline buildpacks are defined as an entry in the `[[build.buildpacks]]` table of the project descriptor by including an `inline` script in the `[build.buildpacks.script]` table.
 
 For example, you may want to run a Rake task against a Ruby app after the Ruby buildpack builds your app.
 
@@ -37,7 +37,7 @@ Inline buildpacks aren't constrained to a single command, however. You can defin
 id = "me/cleanup"
 
   [build.buildpacks.script]
-  api = "0.6"
+  api = "0.9"
   inline = """
 set -e
 source scripts/utils.sh

content/docs/buildpack-author-guide/build-phases-overview.md

@@ -376,4 +376,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 considerd 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 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.

content/docs/buildpack-author-guide/create-buildpack/adding-bill-of-materials.md

@@ -58,7 +58,7 @@ api = "0.8"
   id = "io.buildpacks.samples.stacks.bionic"
 ```
 
-Then, in our buildpack implemetnation we will generate the necessary SBOM metadata:
+Then, in our buildpack implementation we will generate the necessary SBOM metadata:
 
 ```bash
 # ...

content/docs/buildpack-author-guide/publishing-with-github-actions.md

@@ -52,9 +52,9 @@ jobs:
         PACKAGE="${REPO}/$(echo "$BP_ID" | sed 's/\//_/g')"
         pack buildpack package --publish ${PACKAGE}:${VERSION}
         DIGEST="$(crane digest ${PACKAGE}:${VERSION})"
-        echo "::set-output name=bp_id::$BP_ID"
-        echo "::set-output name=version::$VERSION"
-        echo "::set-output name=address::${PACKAGE}@${DIGEST}"
+        echo "bp_id=$BP_ID" >> "$GITHUB_OUTPUT"
+        echo "version=$VERSION" >> "$GITHUB_OUTPUT"
+        echo "address=${PACKAGE}@${DIGEST}" >> "$GITHUB_OUTPUT"
       shell: bash
       env:
         REPO: docker.io/${{ secrets.DOCKER_HUB_USER }}

content/docs/operator-guide/create-a-stack.md

@@ -58,7 +58,7 @@ Next, we will be setting up the base image as required by the [Cloud-Native Buil
 
 
 The `CNB_USER_ID` is the `UID`  of the user as which the `detect` and `build` steps are run. The given user **MUST NOT** be a root user
-and have it's home directly writeable. `CNB_GROUP_ID` is the primary `GID` of the above user.
+and have it's home directly writable. `CNB_GROUP_ID` is the primary `GID` of the above user.
 
 Let's update the `Dockerfile` to reflect the above specification.
 
@@ -111,7 +111,7 @@ docker build . -t cnbs/sample-stack-base:bionic --target base
 
 ### Creating the run image
 
-Next up, we will create the run image. The run image is the base image for your runtime application environemnt.
+Next up, we will create the run image. The run image is the base image for your runtime application environment.
 
 In order to create our run image all we need to do is to set the run image's `USER` to the user with `CNB_USER_ID`. Our final `Dockerfile` for the build image should look like - 
 

content/docs/reference/spec/migration/buildpack-api-0.4-0.5.md

@@ -12,7 +12,7 @@ See the [spec release](https://github.com/buildpacks/spec/releases/tag/buildpack
 The buildpack may now indicate compatibility with any stack by specifying the special value `*`.
 
 ### Character restrictions for process types
-For each process in `launch.toml`, `type` is now restricted to only contain numbers, letters, and the characters `.`, `_`, and `-`, so symlinks on both linux and windows filesystems can be created.
+For each process in `launch.toml`, `type` is now restricted to only contain numbers, letters, and the characters `.`, `_`, and `-`, so symlinks on both Linux and windows filesystems can be created.
 
 ### Override env vars
 Override is now the default behavior for env files without a suffix.