Merge branch 'main' into polish/407

Author: jromero

.github/bug_report.md

@@ -0,0 +1,27 @@
+### **Describe the bug**
+A clear and concise description of what the bug is.
+
+### **To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+### **Expected behavior**
+A clear and concise description of what you expected to happen.
+
+### **Screenshots**
+If applicable, add screenshots or screen captures to help explain your problem.
+
+### **Additional context**
+Add any other context about the problem here.
+
+<hr/>
+
+<!--- Do not remove or change this in the issue description. Only update the details above this. --->
+**Note:**
+* If you want to work on an issue, you should check if it has already been assigned to anyone. **If the issue is free** and you would like to be assigned to it please comment on the issue.
+* If you are raising a new issue and want to work on it then also you should comment to get assigned.
+* Please **refrain from** adding labels to your issue/pull-request on your own. It is the job of the Project Admin and the Mentors to review your issue/pull-request and add labels accordingly.
+

.github/workflows/main.yml

@@ -18,7 +18,7 @@ jobs:
       - name: Git Checkout
         uses: actions/checkout@v2
       - name: Setup Go environment
-        uses: actions/[email protected].3
+        uses: actions/[email protected].4
         with:
           go-version: '1.x'
       - name: Install Dependencies
@@ -35,7 +35,7 @@ jobs:
         run: |
           make check-links
       - name: Upload public folder
-        uses: actions/upload-artifact@v1
+        uses: actions/upload-artifact@v2.2.4
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:
@@ -48,13 +48,14 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Download public folder
-        uses: actions/download-artifact@v1
+        uses: actions/download-artifact@v2.0.10
         with:
           name: public
+          path: ./public
       - name: Deploy
         uses: peaceiris/actions-gh-pages@v3
         with:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           publish_dir: ./public
           cname: buildpacks.io
-          full_commit_message: ${{ github.event.head_commit.message }}
+          full_commit_message: ${{ github.event.head_commit.message }}

content/docs/app-developer-guide/build-a-windows-app.md

@@ -6,7 +6,7 @@ summary="The basics of taking your Windows app from source code to runnable imag
 
 > **EXPERIMENTAL:**
 >
-> - Please note that **Windows container support is currently experimental**. You may be asked to enable experimental features  in `pack` when running the following commands. Simply follow the on-screen instructions to do so.
+> - Please note that **Windows container support is currently experimental**. You may be asked to enable experimental features in `pack` when running the following commands. Simply follow the on-screen instructions to do so.
 > - If you encounter any problems while experimenting, we'd love for you to let us know by filing an issue on the [pack][pack-issues] or [lifecycle][lifecycle-issues] repo.
 
 ### Recommended reading

content/docs/app-developer-guide/build-an-app.md

@@ -55,6 +55,12 @@ docker run --rm -p 8080:8080 sample-app
 
 The app should now be running and accessible via [localhost:8080](http://localhost:8080).
 
+## What about ARM apps?
+
+Linux ARM image builds are now supported!
+
+<a href="/docs/app-developer-guide/build-an-arm-app" class="button bg-blue">Linux ARM build guide</a>
+
 ## What about Windows apps?
 
 Windows image builds are now supported!

content/docs/app-developer-guide/build-an-arm-app.md

@@ -0,0 +1,92 @@
++++
+title="Build an ARM app"
+weight=2
+summary="The basics of taking your app from source code to runnable ARM image."
++++
+
+As of today, there are no CNB platforms (e.g. [pack][pack]) that support building ARM application images. 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
+```
+
+### 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.
+
+```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 xf -
+```
+
+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
+```
+
+And finally we write the `order.toml` file that references the hello-world buildpack.
+
+```bash
+cat > ~/workspace/order.toml <EOF
+[[order]]
+[[order.group]]
+id = "samples/hello-world"
+version = "0.0.1"
+optional = false
+EOF
+```
+
+### 3. Build your app
+
+Now we can build our app. For this example we will be using the docker CLI to invoke the lifecycle directly.
+
+```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:bionic \
+  /cnb/lifecycle/creator -log-level debug -daemon -run-image ubuntu:bionic hello-arm64
+```
+
+### 4. Run it
+
+```bash
+docker run --rm hello-arm64
+```
+
+**Congratulations!**
+
+The app image should now be built and stored on the docker daemon. You may perform `docker images` to verify.
+
+[pack]: https://github.com/buildpacks/pack
+[docker]: https://docs.docker.com
+[samples]: https://github.com/buildpacks/samples
+[lifecycle]: https://github.com/buildpacks/lifecycle

content/docs/app-developer-guide/environment-variables.md

@@ -87,6 +87,7 @@ The following environment variables were set and available to buildpacks at buil
 
 ### Using Project Descriptor
 The `--descriptor` parameter must be a path to a file which follows the project.toml [schema][descriptor-schema].
+Without the `--descriptor` flag, `pack build` will use the `project.toml` file in the application directory if it exists.
 You can define environment variables in an `env` table in the file, and pass those into the application.
 
 ##### Example:

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

@@ -0,0 +1,59 @@
++++
+title="Using Buildpacks with a Proxy"
+weight=8
+summary="Learn how to use buildpacks behind a HTTP proxy."
++++
+
+Many university or corporate environments use a proxy to access HTTP and HTTPS resources on the web.  Proxies introduce two constraints on buildpack built applications:
+
+1. `pack` needs to download buildpacks through the proxies, and
+2. applications running in containers created by `pack` need to call APIs behind the proxy.
+
+We show how to solve both of these constraints.
+
+## Making `pack` Proxy Aware
+
+You may need the `pack` command-line tool to download buildpacks and images via your proxy.  Building an application with an incorrectly configured proxy results in errors such as the following:
+
+```console
+$ pack build sample-app --path samples/apps/java-maven --builder cnbs/sample-builder:bionic
+ERROR: failed to build: failed to fetch builder image 'index.docker.io/cnbs/sample-builder:bionic'
+: Error response from daemon: Get "https//registry-1.docker.io/v2/": context deadline exceeded
+```
+
+The `pack` tool uses the Docker daemon to manage the local image registry on your machine.  The `pack` tool will ask the Docker daemon to download buildpacks and images for you.  Because of this relationship, between `pack` and the Docker daemon, we need to configure the Docker daemon to use a HTTP proxy.  The approach to setting the HTTP proxy depends on your platform:
+
+
+### 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.
+
+### 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.
+
+## Proxy Settings for Buildpacks
+
+Buildpacks may also need to be aware of your http and https proxies at build time.  For example python, java and nodejs buildpacks need to be aware of proxies in order to resolve dependencies.  To make buildpacks aware of proxies, export the `http_proxy` and `https_proxy` environment variables before invoking `pack`.  For example:
+
+```console
+export http_proxy=http://user:[email protected]:3128
+export https_proxy=https://my-proxy.example.com:3129
+pack build sample-app --path samples/apps/java-maven --builder cnbs/sample-builder:bionic
+```
+
+## Making your Application Proxy Aware
+
+Your application may need to use http or https proxies to access web-based APIs.  In order to make proxy settings available inside containers you should edit your `~/.docker/config.json` file (`%USERPROFILE%\.docker\config.json` on Windows) to contain the proxy information.  The `httpProxy`, `httpsProxy` and `noProxy` properties of this configuration file are injected into containers at build time and at run time as the `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables respectively.  Both the http and https proxy settings are also injected in their lower-case form as `http_proxy` and `https_proxy`.
+
+```json
+{
+  "proxies": {
+    "default": {
+      "httpProxy":  "http://user:[email protected]:3128",
+      "httpsProxy": "https://my-proxy.example.com:3129",
+      "noProxy":    "internal.mycorp.example.com"
+    }
+  }
+}
+```
+
+If your application requires a http or https proxy, then you should prefer to read proxy information from the lower-case `http_proxy` and `https_proxy` variables.

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

@@ -0,0 +1,58 @@
++++
+title="Using Inline Buildpacks"
+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.
+
+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.
+
+For example, you may want to run a Rake task against a Ruby app after the Ruby buildpack builds your app.
+
+```toml
+[project]
+id = "io.buildpacks.my-app"
+
+[[build.buildpacks]]
+id = "example/ruby"
+version = "1.0"
+
+[[build.buildpacks]]
+id = "me/rake-tasks"
+
+  [build.buildpacks.script]
+  api = "0.6"
+  inline = "rake package"
+```
+
+In this example, the `me/rake-tasks` inline buildpack is configured to run after the `example/ruby` buildpack. The inline script is compatible with API version `0.4` (this is a required field), and it will execute the `rake package` command during the build step.
+
+> **Note:** Inline buildpacks will _always_ pass detection.
+
+Inline buildpacks aren't constrained to a single command, however. You can define complex scripts as [heredocs](https://toml.io/en/v1.0.0#string) in your project descriptor. For example, this snippet of a descriptor will source a shell script contained in the app repo, use it to modify the app directory (and thus the files that go into the final image), and create slices for the app:
+
+```toml
+[[build.buildpacks]]
+id = "me/cleanup"
+
+  [build.buildpacks.script]
+  api = "0.6"
+  inline = """
+set -e
+source scripts/utils.sh
+find . -type f -name $(my_data_files) -delete
+cat <<EOF > ${1}/launch.toml
+[[processes]]
+type = 'bash'
+command = 'bin/bash'
+EOF
+"""
+```
+
+### Further Reading
+For more about project descriptors, look at the [schema][descriptor-schema], as well as the [specification][spec].
+
+[project-toml]: /docs/app-developer-guide/using-project-descriptor/
+[descriptor-schema]: /docs/reference/project-descriptor/
+[spec]: https://github.com/buildpacks/spec/blob/main/extensions/project-descriptor.md

content/docs/buildpack-author-guide/create-buildpack/building-blocks-cnb.md

@@ -11,7 +11,7 @@ Let's create the directory where your buildpack will live:
 
 ## Using the Pack CLI
 
-The `buildpack new <id>` commmand will create a directory named for the buildpack ID.
+The `buildpack new <id>` command will create a directory named for the buildpack ID.
 
 Example:
 <!-- test:exec -->

content/docs/buildpack-author-guide/create-buildpack/detection.md

@@ -5,7 +5,7 @@ weight=403
 
 <!-- test:suite=create-buildpack;weight=3 -->
 
-Next, you will want to actually detect that the app your are building is a Ruby app. In order to do this, you will need to check for a `Gemfile`.
+Next, you will want to actually detect that the app you are building is a Ruby app. In order to do this, you will need to check for a `Gemfile`.
 
 Replace `exit 1` in the `detect` script with the following check:
 
@@ -50,7 +50,7 @@ You should see the following output:
 
 Notice that `detect` now passes because there is a valid `Gemfile` in the Ruby app at `ruby-sample-app`, but now `build` fails because it is currently written to error out.
 
-You will also notice that `ANALYZING` now appears in the build output. This steps is part of the buildpack lifecycle that looks to see if any previous image builds have layers that the buildpack can re-use. We will get into this topic in more detail later.
+You will also notice that `ANALYZING` now appears in the build output. This step is part of the buildpack lifecycle that looks to see if any previous image builds have layers that the buildpack can re-use. We will get into this topic in more detail later.
 
 ---