Merge pull request cds-hooks#416 from aemengo/add-arm-docs

Add ARM docs

Author: Natalie Arellano

.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/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.
 
 ---
 

content/docs/buildpack-author-guide/publish-a-buildpack.md

@@ -27,7 +27,7 @@ pack buildpack register example/my-cnb
 
 This will open GitHub in a browser and may ask you to authenticate with GitHub. After doing so, you'll see a pre-populated GitHub Issue with the details of your buildpack. For example:
 
-<img src="/images/registry-add-buildpack.png" />
+<img src="/images/registry-add-buildpack.png" alt="pre-populated GitHub Issue" />
 
 The pre-populated text in the body of the issue is considered structured data, and will be used to automatically add the buildpack to the registry index. Do not change it.
 

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

@@ -4,7 +4,7 @@ weight=5
 summary="Learn how to automatically publish your buildpack to the Buildpack Registry from a Github Action."
 +++
 
-If you would like to publish your buildpack image to the registry without requiring a human click a button in a browser, you can automate the process using the helpers in the [buildpacks/github-actions][github-actions] repository.
+If you would like to publish your buildpack image to the registry without requiring a human to click a button in a browser, you can automate the process using the helpers in the [buildpacks/github-actions][github-actions] repository.
 
 To begin, you must store your buildpack source code in GitHub and [enable GitHub Actions](https://github.com/features/actions). Then create a directory named `.github/workflows` in your repository, and add a file named `release.yml` to it. The `release.yml` workflow can be [triggered](https://docs.github.com/en/actions/reference/events-that-trigger-workflows) in many ways, but it's common to use a Release event as a trigger. To do so, add the following to your `release.yml`:
 
@@ -75,7 +75,7 @@ Before you execute this GitHub Action, you must add three secrets to your GitHub
 
 After you've created these secrets and pushed your `release.yml` file to GitHub you can trigger the workflow by creating a new Release using the [GitHub Releases UI](https://docs.github.com/en/github/administering-a-repository/about-releases).
 
-From [GitHub.com](https://github.com), click on _Your Repositories_, then click the _Packages_ tab and look for the image you just created. Click it and then select _Package Settings_. From this page, click the button to make this package public, and confirm the name of the image when promoted.
+From [GitHub.com](https://github.com), click on _Your Repositories_, then click the _Packages_ tab and look for the image you just created. Click it and then select _Package Settings_. From this page, click the button to make this package public, and confirm the name of the image when prompted.
 
 Push the `release.yml` changes to GitHub and trigger a new release. The workflow will create a GitHub Issue on the Buildpack Registry and your buildpack will be added to the index.
 

content/docs/concepts/components/buildpack-group.md

@@ -24,7 +24,7 @@ A [builder][builder] or [meta-buildpack][meta-buildpack] may contain multiple bu
 
 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 containg buildpack group.
+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.
 
 For example: