remove knative build from everywhere (#1656)

2019-08-08 08:42:56 -07:00 · 2019-08-08 08:42:56 -07:00 · e1a90c498b
parent bb824f1f97
commit e1a90c498b
45 changed files with 25 additions and 3151 deletions
--- a/community/samples/README.md
+++ b/community/samples/README.md
@ -16,11 +16,8 @@ Knative Serving sample apps.
 | ----------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | Hello World | A quick introduction to Knative Serving that highlights how to deploy an app. | [Clojure](./serving/helloworld-clojure/README.md), [Dart](./serving/helloworld-dart/README.md), [Elixir](./serving/helloworld-elixir/README.md), [Haskell](./serving/helloworld-haskell/README.md), [Java - Micronaut](./serving/helloworld-java-micronaut/README.md), [Java - Quarkus](./serving/helloworld-java-quarkus/README.md), [Rust](./serving/helloworld-rust/README.md), [Swift](./serving/helloworld-swift/README.md), [Vertx](./serving/helloworld-vertx/README.md) |
 #### Build samples
- _Be the first to contribute a Build code sample to the community collection._
+#### Eventing and Eventing Resources samples
 #### Eventing and Eventing Sources samples
 - _Be the first to contribute an Eventing or Eventing Sources code sample to the
  community collection._
--- a/docs/README.md
+++ b/docs/README.md
@ -1,3 +1,4 @@
 Knative (pronounced kay-nay-tiv) extends
 [Kubernetes](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
 to provide a set of middleware components that are essential to build modern,
@ -19,9 +20,8 @@ deploy functions, applications, or containers workloads.
 ## Components
-The following Knative components are available:
+Knative consists of the Serving and Eventing components:
 - [Build](./build) - Source-to-container build orchestration
 - [Eventing](./eventing) - Management and delivery of events
 - [Serving](./serving) - Request-driven compute that can scale to zero
@ -64,7 +64,6 @@ following components:
 - [serving](https://github.com/knative/serving/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Akind%2Fgood-first-issue)
 - [eventing](https://github.com/knative/eventing/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Akind%2Fgood-first-issue)
 - [build](https://github.com/knative/build/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Akind%2Fgood-first-issue)
 - [documentation](https://github.com/knative/docs/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Akind%2Fgood-first-issue)
 [Bug reports](https://github.com/knative/serving/issues/new) and friction logs
@ -79,7 +78,6 @@ Follow the links below to learn more about Knative.
 - [Installing Knative](./install/README.md)
 - [Getting started with app deployment](./install/getting-started-knative-app.md)
 - [Getting started with serving](./serving)
 - [Getting started with builds](./build)
 - [Getting started with eventing](./eventing)
 ### Configuration and networking
@ -110,10 +108,3 @@ Follow the links below to learn more about Knative.
 - [Debugging application issues](./serving/debugging-application-issues.md)
 - [Debugging performance issues](./serving/debugging-performance-issues.md)
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/build/README.md
+++ b/docs/build/README.md
@ -1,94 +1,6 @@
 A `Build` is a custom resource in Knative that allows you to define a process
 that runs to completion and can provide status. For example, fetch, build, and
 package your code by using a Knative `Build` that communicates whether the
 process succeeds.
-A Knative `Build` runs on-cluster and is implemented by a
+The Knative Build component has been deprecated. For more information,
-[Kubernetes Custom Resource Definition (CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
+see the [**knative/build repository**](https://github.com/knative/build/blob/master/README.md).
-Given a _builder_, or container image that you have created to perform a task or
+Documentation for the final release of Knative Build is available in the
-action, you can define a Knative `Build` through a single configuration file.
+[**v0.7 docs release**](../v0.7-docs/build/).
 ## Key features of Knative Builds
 - A `Build` can include multiple `steps` where each step specifies a `Builder`.
 - A _builder_ is a type of container image that you create to accomplish any
  task, whether that's a single step in a process, or the whole process itself.
 - The `steps` in a `Build` can push to a registry.
 - A `BuildTemplate` can be used to define reusable templates.
 - The `source` in a `Build` can be defined to mount data to a Kubernetes Volume,
  and supports:
  - `git` repositories
  - Google Cloud Storage
  - An arbitrary container image
 - Authenticate with `ServiceAccount` using Kubernetes Secrets.
 ### Learn more
 See the following reference topics for information about each of the build
 components:
 - [`Build`](./builds.md)
 - [`BuildTemplate`](./build-templates.md)
 - [`Builder`](./builder-contract.md)
 - [`ServiceAccount`](./auth.md)
 ## Install the Knative Build component
 Because all Knative components stand alone, you can decide which components to
 install. Knative Serving is not required to create and run builds.
 Before you can run a Knative Build, you must install the Knative Build component
 in your Kubernetes cluster:
 - For details about installing a new instance of Knative in your Kubernetes
  cluster, see [Installing Knative](../install/README.md).
 - If you have a component of Knative installed and running, you can
  [add and install the Knative Build component](./installing-build-component.md).
 ## Configuration syntax example
 Use the following example to understand the syntax and structure of the various
 components of a Knative `Build`. Note that not all elements of a `Build`
 configuration file are included in the following example but you can reference
 the [Knative Build samples](#get-started-with-knative-build-samples) section
 along with the [reference files](#learn-more) above for more information.
 The following example demonstrates a build that uses authentication and includes
 multiple `steps` and multiple repositories:
 ```yaml
 apiVersion: build.knative.dev/v1alpha1
 kind: Build
 metadata:
  name: example-build
 spec:
  serviceAccountName: build-auth-example
  source:
    git:
      url: https://github.com/example/build-example.git
      revision: master
  steps:
    - name: ubuntu-example
      image: ubuntu
      args: ["ubuntu-build-example", "SECRETS-example.md"]
    - image: gcr.io/example-builders/build-example
      args: ["echo", "hello-example", "build"]
 ```
 ## Get started with Knative Build samples
 [See Knative Build code samples](./samples.md)
 ## Related info
 If you are interested in contributing to the Knative Build project, see the
 [Knative Build code repository](https://github.com/knative/build).
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/build/_index.md
+++ b/docs/build/_index.md
@ -1,8 +1,8 @@
 ---
-title: "Knative Build"
+title: "Deprecated: Knative Build Component"
-linkTitle: "Build Component"
+linkTitle: "(Deprecated) Build"
-weight: 20
+weight: 200
 type: "docs"
 ---
-{{% readfile file="README.md" relative="true" markdown="true" %}}
+{{% readfile file="README.md" %}}
--- a/docs/build/auth.md
+++ b/docs/build/auth.md
@ -1,402 +0,0 @@
 ---
 title: "Authentication"
 #linkTitle: "OPTIONAL_ALTERNATE_NAV_TITLE"
 weight: 25
 type: "docs"
 ---
 This document defines how authentication is provided during execution of a
 build.
 The build system supports two types of authentication, using Kubernetes'
 first-class `Secret` types:
 - `kubernetes.io/basic-auth`
 - `kubernetes.io/ssh-auth`
 Secrets of these types can be made available to the `Build` by attaching them to
 the `ServiceAccount` as which it runs.
 ### Exposing credentials to the build
 In their native form, these secrets are unsuitable for consumption by Git and
 Docker. For Git, they need to be turned into (some form of) `.gitconfig`. For
 Docker, they need to be turned into a `~/.docker/config.json` file. Also, while
 each of these supports has multiple credentials for multiple domains, those
 credentials typically need to be blended into a single canonical keyring.
 To solve this, before the `Source` step, all builds execute a credential
 initialization process that accesses each of its secrets and aggregates them
 into their respective files in `$HOME`.
 ## SSH authentication (Git)
 1.  Define a `Secret` containing your SSH private key:
    ```yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: ssh-key
      annotations:
        build.knative.dev/git-0: https://github.com # Described below
    type: kubernetes.io/ssh-auth
    data:
      ssh-privatekey: <base64 encoded>
      # This is non-standard, but its use is encouraged to make this more secure.
      known_hosts: <base64 encoded>
    ```
    `build.knative.dev/git-0` in the example above specifies which web address
    these credentials belong to. See
    [Guiding Credential Selection](#guiding-credential-selection) below for more
    information.
 1.  Generate the value of `ssh-privatekey` by copying the value of (for example)
    `cat ~/.ssh/id_rsa | base64`.
 1.  Copy the value of `cat ~/.ssh/known_hosts | base64` to the `known_hosts`
    field.
 1.  Next, direct a `ServiceAccount` to use this `Secret`:
    ```yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: build-bot
    secrets:
      - name: ssh-key
    ```
 1.  Then use that `ServiceAccount` in your `Build`:
    ```yaml
    apiVersion: build.knative.dev/v1alpha1
    kind: Build
    metadata:
      name: build-with-ssh-auth
    spec:
      serviceAccountName: build-bot
      steps:
      ...
    ```
 1.  Execute the build:
    ```shell
    kubectl apply --filename secret.yaml --filename serviceaccount.yaml --filename build.yaml
    ```
 When the build executes, before steps execute, a `~/.ssh/config` will be
 generated containing the key configured in the `Secret`. This key is then used
 to authenticate with the Git service.
 ## Basic authentication (Git)
 1.  Define a `Secret` containing the username and password that the build should
    use to authenticate to a Git repository:
    ```yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: basic-user-pass
      annotations:
        build.knative.dev/git-0: https://github.com # Described below
    type: kubernetes.io/basic-auth
    stringData:
      username: <username>
      password: <password>
    ```
    `build.knative.dev/git-0` in the example above specifies which web address
    these credentials belong to. See
    [Guiding Credential Selection](#guiding-credential-selection) below for more
    information.
 1.  Next, direct a `ServiceAccount` to use this `Secret`:
    ```yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: build-bot
    secrets:
      - name: basic-user-pass
    ```
 1.  Use that `ServiceAccount` in your `Build`:
    ```yaml
    apiVersion: build.knative.dev/v1alpha1
    kind: Build
    metadata:
      name: build-with-basic-auth
    spec:
      serviceAccountName: build-bot
      steps:
      ...
    ```
 1.  Execute the build:
    ```shell
    kubectl apply --filename secret.yaml --filename serviceaccount.yaml --filename build.yaml
    ```
 When this build executes, before steps execute, a `~/.gitconfig` will be
 generated containing the credentials configured in the `Secret`, and these
 credentials are then used to authenticate with the Git repository.
 ## Basic authentication (Docker)
 1.  Define a `Secret` containing the username and password that the build should
    use to authenticate to a Docker registry:
    ```yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: basic-user-pass
      annotations:
        build.knative.dev/docker-0: https://gcr.io # Described below
    type: kubernetes.io/basic-auth
    stringData:
      username: <username>
      password: <password>
    ```
    `build.knative.dev/docker-0` in the example above specifies which web
    address these credentials belong to. See
    [Guiding Credential Selection](#guiding-credential-selection) below for more
    information.
 1.  Direct a `ServiceAccount` to use this `Secret`:
    ```yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: build-bot
    secrets:
      - name: basic-user-pass
    ```
 1.  Use that `ServiceAccount` in your `Build`:
    ```yaml
    apiVersion: build.knative.dev/v1alpha1
    kind: Build
    metadata:
      name: build-with-basic-auth
    spec:
      serviceAccountName: build-bot
      steps:
      ...
    ```
 1.  Execute the build:
    ```shell
    kubectl apply --filename secret.yaml --filename serviceaccount.yaml --filename build.yaml
    ```
 When this build executes, before steps execute, a `~/.docker/config.json` will
 be generated containing the credentials configured in the `Secret`, and these
 credentials are then used to authenticate with the Docker registry.
 ## Kubernetes's Docker registry's secret
 Kubernetes defines two types of secrets for Docker registries :
 `kubernetes.io/dockercfg` and `kubernetes.io/dockerconfigjson`. Knative supports
 those secrets in addition to the one described above.
 1. Define a `Secret` from a Docker client configuration file, as documented in
   [Pull an Image from a Private Registry](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/)
   ```bash
   kubectl create secret generic regcred \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson
   ```
 1. Direct a `ServiceAccount` to use this `Secret`:
   ```yaml
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: build-bot
   secrets:
     - name: regcred
   ```
 1. Use that `ServiceAccount` in your `Build`:
   ```yaml
   apiVersion: build.knative.dev/v1alpha1
   kind: Build
   metadata:
     name: build-with-basic-auth
   spec:
     serviceAccountName: build-bot
     steps:
     ...
   ```
 1. Execute the build:
   ```shell
   kubectl apply --filename secret.yaml --filename serviceaccount.yaml --filename build.yaml
   ```
 When this build executes, before steps execute, a `~/.docker/config.json` will
 be generated containing the credentials configured in the `Secret`, and these
 credentials are then used to authenticate with the Docker registry.
 If both `kubernetes.io/*` and knative flavored basic authentication secret are
 provided, knative will merge the credentials from those two ; knative flavored
 credentials taking precedence over `kubernetes.io/dockerconfigjson` (or
 `kubernetes.io/dockercfg`) ones.
 ### Guiding credential selection
 A build might require many different types of authentication. For instance, a
 build might require access to multiple private Git repositories, and access to
 many private Docker repositories. You can use annotations to guide which secret
 to use to authenticate to different resources, for example:
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
  annotations:
    build.knative.dev/git-0: https://github.com
    build.knative.dev/git-1: https://gitlab.com
    build.knative.dev/docker-0: https://gcr.io
 type: kubernetes.io/basic-auth
 stringData:
  username: <cleartext non-encoded>
  password: <cleartext non-encoded>
 ```
 This describes a "Basic Auth" (username and password) secret that should be used
 to access Git repos at github.com and gitlab.com, as well as Docker repositories
 at gcr.io.
 Similarly, for SSH:
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
  annotations:
    build.knative.dev/git-0: github.com
 type: kubernetes.io/ssh-auth
 data:
  ssh-privatekey: <base64 encoded>
  # This is non-standard, but its use is encouraged to make this more secure.
  # Omitting this results in the use of ssh-keyscan (see below).
  known_hosts: <base64 encoded>
 ```
 This describes an SSH key secret that should be used to access Git repos at
 github.com only.
 Credential annotation keys must begin with `build.knative.dev/docker-` or
 `build.knative.dev/git-`, and the value describes the URL of the host with which
 to use the credential.
 ## Implementation detail
 ### Docker `basic-auth`
 Given URLs, usernames, and passwords of the form: `https://url{n}.com`,
 `user{n}`, and `pass{n}`, generate the following for Docker:
 ```json
 === ~/.docker/config.json ===
 {
  "auths": {
    "https://url1.com": {
      "auth": "$(echo -n user1:pass1 | base64)",
      "email": "not@val.id",
    },
    "https://url2.com": {
      "auth": "$(echo -n user2:pass2 | base64)",
      "email": "not@val.id",
    },
    ...
  }
 }
 ```
 Docker doesn't support `kubernetes.io/ssh-auth`, so annotations on these types
 are ignored.
 ### Git `basic-auth`
 Given URLs, usernames, and passwords of the form: `https://url{n}.com`,
 `user{n}`, and `pass{n}`, generate the following for Git:
 ```
 === ~/.gitconfig ===
 [credential]
 	helper = store
 [credential "https://url1.com"]
    username = "user1"
 [credential "https://url2.com"]
    username = "user2"
 ...
 === ~/.git-credentials ===
 https://user1:pass1@url1.com
 https://user2:pass2@url2.com
 ...
 ```
 ### Git `ssh-auth`
 Given hostnames, private keys, and `known_hosts` of the form: `url{n}.com`,
 `key{n}`, and `known_hosts{n}`, generate the following for Git:
 ```
 === ~/.ssh/id_key1 ===
 {contents of key1}
 === ~/.ssh/id_key2 ===
 {contents of key2}
 ...
 === ~/.ssh/config ===
 Host url1.com
    HostName url1.com
    IdentityFile ~/.ssh/id_key1
 Host url2.com
    HostName url2.com
    IdentityFile ~/.ssh/id_key2
 ...
 === ~/.ssh/known_hosts ===
 {contents of known_hosts1}
 {contents of known_hosts2}
 ...
 ```
 Note: Because `known_hosts` is a non-standard extension of
 `kubernetes.io/ssh-auth`, when it is not present this will be generated through
 `ssh-keygen url{n}.com` instead.
 ### Least privilege
 The secrets as outlined here will be stored into `$HOME` (by convention the
 volume: `/builder/home`), and will be available to `Source` and all `Steps`.
 For sensitive credentials that should not be made available to some steps, do
 not use the mechanisms outlined here. Instead, the user should declare an
 explicit `Volume` from the `Secret` and manually `VolumeMount` it into the
 `Step`.
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/build/build-templates.md
+++ b/docs/build/build-templates.md
@ -1,164 +0,0 @@
 ---
 title: "Build templates"
 #linkTitle: "OPTIONAL_ALTERNATE_NAV_TITLE"
 weight: 35
 type: "docs"
 ---
 This document defines "Build Templates" and their capabilities.
 A set of curated and supported build templates is available in the
 [`build-templates`](https://github.com/knative/build-templates) repo.
 ## What is a Build Template?
 A `BuildTemplate` and `ClusterBuildTemplate` encapsulates a shareable
 [build](./builds.md) process with some limited parameterization capabilities.
 A `BuildTemplate` is available within a namespace, and `ClusterBuildTemplate` is
 available across entire Kubernetes cluster.
 A `BuildTemplate` functions exactly like a `ClusterBuildTemplate`, and as such
 all references to `BuildTemplate` below are also describing
 `ClusterBuildTemplate`.
 ### Example template
 For example, a `BuildTemplate` to encapsulate a `Dockerfile` build might look
 something like this:
 **Note:** Building a container image using `docker build` on-cluster is _very
 unsafe_. Use [kaniko](https://github.com/GoogleContainerTools/kaniko) instead.
 This is used only for the purposes of demonstration.
 ```yaml
 spec:
  parameters:
    # This has no default, and is therefore required.
    - name: IMAGE
      description: Where to publish the resulting image.
    # These may be overridden, but provide sensible defaults.
    - name: DIRECTORY
      description: The directory containing the build context.
      default: /workspace
    - name: DOCKERFILE_NAME
      description: The name of the Dockerfile
      default: Dockerfile
  steps:
    - name: dockerfile-build
      image: gcr.io/cloud-builders/docker
      workingDir: "${DIRECTORY}"
      args:
        [
          "build",
          "--no-cache",
          "--tag",
          "${IMAGE}",
          "--file",
          "${DOCKERFILE_NAME}",
          ".",
        ]
      volumeMounts:
        - name: docker-socket
          mountPath: /var/run/docker.sock
    - name: dockerfile-push
      image: gcr.io/cloud-builders/docker
      args: ["push", "${IMAGE}"]
      volumeMounts:
        - name: docker-socket
          mountPath: /var/run/docker.sock
  # As an implementation detail, this template mounts the host's daemon socket.
  volumes:
    - name: docker-socket
      hostPath:
        path: /var/run/docker.sock
        type: Socket
 ```
 In this example, `parameters` describes the formal arguments for the template.
 The `description` is used for diagnostic messages during validation (and maybe
 in the future for UI). The `default` value enables a template to have a
 graduated complexity, where options are overridden only when the user strays
 from some set of sane defaults.
 The `steps` and `volumes` parameters are just like in a [`Build`](./builds.md)
 resource, but might contain references to parameters in the form:
 `${PARAMETER_NAME}`.
 The `steps` of a template replace those of its Build. The `volumes` of a
 template augment those of its Build.
 ### Example Builds
 For the sake of illustrating re-use, here are several example Builds
 instantiating the `BuildTemplate` above (`dockerfile-build-and-push`).
 Build `mchmarny/rester-tester`:
 ```yaml
 spec:
  source:
    git:
      url: https://github.com/mchmarny/rester-tester.git
      revision: master
  template:
    name: dockerfile-build-and-push
    kind: BuildTemplate
    arguments:
      - name: IMAGE
        value: gcr.io/my-project/rester-tester
 ```
 Build `googlecloudplatform/cloud-builder`'s `wget` builder:
 ```yaml
 spec:
  source:
    git:
      url: https://github.com/googlecloudplatform/cloud-builders.git
      revision: master
  template:
    name: dockerfile-build-and-push
    kind: BuildTemplate
    arguments:
      - name: IMAGE
        value: gcr.io/my-project/wget
      # Optional override to specify the subdirectory containing the Dockerfile
      - name: DIRECTORY
        value: /workspace/wget
 ```
 Build `googlecloudplatform/cloud-builder`'s `docker` builder with `17.06.1`:
 ```yaml
 spec:
  source:
    git:
      url: https://github.com/googlecloudplatform/cloud-builders.git
      revision: master
  template:
    name: dockerfile-build-and-push
    kind: BuildTemplate
    arguments:
      - name: IMAGE
        value: gcr.io/my-project/docker
      # Optional overrides
      - name: DIRECTORY
        value: /workspace/docker
      - name: DOCKERFILE_NAME
        value: Dockerfile-17.06.1
 ```
 The `spec.template.kind` is optional and defaults to `BuildTemplate`.
 Alternately it could have value `ClusterBuildTemplate`.
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/build/builder-contract.md
+++ b/docs/build/builder-contract.md
@ -1,79 +0,0 @@
 ---
 title: "Builders"
 #linkTitle: "OPTIONAL_ALTERNATE_NAV_TITLE"
 weight: 15
 type: "docs"
 ---
 This document defines builder images and the conventions to which they are
 expected to adhere.
 ## What is a builder?
 A builder image is a special classification for images that run as a part of the
 Build CRD's `steps`.
 For example, in the following Build the images, `gcr.io/cloud-builders/gcloud`
 and `gcr.io/cloud-builders/docker` are "builders":
 ```yaml
 spec:
  steps:
  - image: gcr.io/cloud-builders/gcloud
    ...
  - image: gcr.io/cloud-builders/docker
    ...
 ```
 ### Typical builders
 A builder is typically a purpose-built container whose entrypoint is a tool that
 performs some action and exits with a zero status on success. These entrypoints
 are often command-line tools, for example, `git`, `docker`, `mvn`, and so on.
 Typical builders set their `command:` (aka `ENTRYPOINT`) to be the command they
 wrap and expect to take `args:` to direct their behavior.
 See [here](https://github.com/googlecloudplatform/cloud-builders) and
 [here](https://github.com/googlecloudplatform/cloud-builders-community) for more
 builders.
 ### Atypical builders
 It is possible, although less typical to implement the builder convention by
 overriding `command:` and `args:` for example:
 ```yaml
 steps:
  - image: ubuntu
    command: ["/bin/bash"]
    args: ["-c", "echo hello $FOO"]
    env:
      - name: "FOO"
        value: "world"
 ```
 ### Specialized builders
 It is also possible for advanced users to create purpose-built builders. One
 example of this are the
 ["FTL" builders](https://github.com/GoogleCloudPlatform/runtimes-common/tree/master/ftl#ftl).
 ## What are the builder conventions?
 Builders should expect a Build to implement the following conventions:
 - `/workspace`: The default working directory will be `/workspace`, which is a
  volume that is filled by the `source:` step and shared across build `steps:`.
 - `/builder/home`: This volume is exposed to steps via `$HOME`.
 - Credentials attached to the Build's service account may be exposed as Git or
  Docker credentials as outlined [here](./auth.md).
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/build/builds.md
+++ b/docs/build/builds.md
@ -1,366 +0,0 @@
 ---
 title: "Knative Build resources"
 linkTitle: "Build resources"
 weight: 5
 type: "docs"
 ---
 Use the `Build` resource object to create and run on-cluster processes to
 completion.
 To create a build in Knative, you must define a configuration file, in which
 specifies one or more container images that you have implemented to perform and
 complete a task.
 A build runs until all `steps` have completed or until a failure occurs.
 ---
 - [Syntax](#syntax)
  - [Steps](#steps)
  - [Template](#template)
  - [Source](#source)
  - [Service Account](#service-account)
  - [Volumes](#volumes)
  - [Timeout](#timeout)
 - [Examples](#examples)
 ---
 ### Syntax
 To define a configuration file for a `Build` resource, you can specify the
 following fields:
 - Required:
  - [`apiVersion`][kubernetes-overview] - Specifies the API version, for example
    `build.knative.dev/v1alpha1`.
  - [`kind`][kubernetes-overview] - Specify the `Build` resource object.
  - [`metadata`][kubernetes-overview] - Specifies data to uniquely identify the
    `Build` resource object, for example a `name`.
  - [`spec`][kubernetes-overview] - Specifies the configuration information for
    your `Build` resource object. Build steps must be defined through either of
    the following fields:
    - [`steps`](#steps) - Specifies one or more container images that you want
      to run in your build.
    - [`template`](#template) - Specifies a reusable build template that
      includes one or more `steps`.
 - Optional:
  - [`source`](#source) - Specifies a container image that provides information
    to your build.
  - [`serviceAccountName`](#service-account) - Specifies a `ServiceAccount`
    resource object that enables your build to run with the defined
    authentication information.
  - [`volumes`](#volumes) - Specifies one or more volumes that you want to make
    available to your build.
  - [`timeout`](#timeout) - Specifies timeout after which the build will fail.
 [kubernetes-overview]:
  https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#required-fields
 The following example is a non-working sample where most of the possible
 configuration fields are used:
 ```yaml
 apiVersion: build.knative.dev/v1alpha1
 kind: Build
 metadata:
  name: example-build-name
 spec:
  serviceAccountName: build-auth-example
  source:
    git:
      url: https://github.com/example/build-example.git
      revision: master
  steps:
    - name: ubuntu-example
      image: ubuntu
      args: ["ubuntu-build-example", "SECRETS-example.md"]
    - image: gcr.io/example-builders/build-example
      args: ["echo", "hello-example", "build"]
    - name: dockerfile-pushexample
      image: gcr.io/example-builders/push-example
      args: ["push", "${IMAGE}"]
      volumeMounts:
        - name: docker-socket-example
          mountPath: /var/run/docker.sock
  volumes:
    - name: example-volume
      emptyDir: {}
 ```
 #### Steps
 The `steps` field is required if the `template` field is not defined.
 Each `steps` field in a build must specify a `Builder`, or type of container
 image that adheres to the [Knative builder contract](./builder-contract.md). For
 each of the `steps` fields, or container images that you define:
 - The `Builder`-type container images are run and evaluated in order, starting
  from the top of the configuration file.
 - Each container image runs until completion or until the first failure is
  detected.
 For details about how to ensure that you implement each step to align with the
 "builder contract", see the [`Builder`](./builder-contract.md) reference topic.
 #### Template
 The `template` field is a required if no `steps` are defined. Specifies a
 [`BuildTemplate`](./build-templates.md) resource object, in which includes
 repeatable or sharable build `steps`.
 For examples and more information about build templates, see the
 [`BuildTemplate`](./build-templates.md) reference topic.
 #### Source
 Optional. Specifies a container image. Use the `source` field to provide your
 build with data or context that is needed by your build. The data is placed into
 the `/workspace` directory within a mounted
 [volume](https://kubernetes.io/docs/concepts/storage/volumes/) and is available
 to all `steps` of your build.
 The currently supported types of sources include:
 - `git` - A Git based repository. Specify the `url` field to define the location
  of the container image. Specify a `revision` field to define a branch name,
  tag name, commit SHA, or any ref.
  [Learn more about revisions in Git](https://git-scm.com/docs/gitrevisions#_specifying_revisions).
 - `gcs` - An archive that is located in Google Cloud Storage.
 - `custom` - An arbitrary container image.
 #### Service Account
 Optional. Specifies the `name` of a `ServiceAccount` resource object. Use the
 `serviceAccountName` field to run your build with the privileges of the
 specified service account. If no `serviceAccountName` field is specified, your
 build runs using the
 [`default` service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)
 that is in the
 [namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
 of the `Build` resource object.
 For examples and more information about specifying service accounts, see the
 [`ServiceAccount`](./auth.md) reference topic.
 #### Volumes
 Optional. Specifies one or more
 [volumes](https://kubernetes.io/docs/concepts/storage/volumes/) that you want to
 make available to your build, including all the build steps. Add volumes to
 complement the volumes that are implicitly
 [created during a build step](./builder-contract.md).
 For example, use volumes to accomplish one of the following common tasks:
 - [Mount a Kubernetes secret](./auth.md).
 - Create an `emptyDir` volume to act as a cache for use across multiple build
  steps. Consider using a persistent volume for inter-build caching.
 - Mount a host's Docker socket to use a `Dockerfile` for container image builds.
 #### Timeout
 Optional. Specifies timeout for the build. Includes time required for allocating
 resources and execution of build.
 - Defaults to 10 minutes.
 - Refer to
  [Go's ParseDuration documentation](https://golang.org/pkg/time/#ParseDuration)
  for expected format.
 ### Examples
 Use these code snippets to help you understand how to define your Knative
 builds.
 Tip: See the collection of simple
 [test builds](https://github.com/knative/build/tree/master/test) for additional
 code samples, including working copies of the following snippets:
 - [`git` as `source`](#using-git)
 - [`gcs` as `source`](#using-gcs)
 - [`custom` as `source`](#using-custom)
 - [Mounting extra volumes](#using-an-extra-volume)
 - [Pushing an image](#using-steps-to-push-images)
 - [Authenticating with `ServiceAccount`](#using-a-serviceaccount)
 - [Timeout](#using-timeout)
 #### Using `git`
 Specifying `git` as your `source`:
 ```yaml
 spec:
  source:
    git:
      url: https://github.com/knative/build.git
      revision: master
  steps:
    - image: ubuntu
      args: ["cat", "README.md"]
 ```
 #### Using `gcs`
 Specifying `gcs` as your `source`:
 ```yaml
 spec:
  source:
    gcs:
      type: Archive
      location: gs://build-crd-tests/rules_docker-master.zip
  steps:
    - name: list-files
      image: ubuntu:latest
      args: ["ls"]
 ```
 #### Using `custom`
 Specifying `custom` as your `source`:
 ```yaml
 spec:
  source:
    custom:
      image: gcr.io/cloud-builders/gsutil
      args: ["rsync", "gs://some-bucket", "."]
  steps:
    - image: ubuntu
      args: ["cat", "README.md"]
 ```
 #### Using an extra volume
 Mounting multiple volumes:
 ```yaml
 spec:
  steps:
    - image: ubuntu
      entrypoint: ["bash"]
      args: ["-c", "curl https://foo.com > /var/my-volume"]
      volumeMounts:
        - name: my-volume
          mountPath: /var/my-volume
    - image: ubuntu
      args: ["cat", "/etc/my-volume"]
      volumeMounts:
        - name: my-volume
          mountPath: /etc/my-volume
  volumes:
    - name: my-volume
      emptyDir: {}
 ```
 #### Using `steps` to push images
 Defining a `steps` to push a container image to a repository.
 ```yaml
 spec:
  parameters:
    - name: IMAGE
      description: The name of the image to push
    - name: DOCKERFILE
      description: Path to the Dockerfile to build.
      default: /workspace/Dockerfile
  steps:
    - name: build-and-push
      image: gcr.io/kaniko-project/executor
      args:
        - --dockerfile=${DOCKERFILE}
        - --destination=${IMAGE}
 ```
 #### Using a `ServiceAccount`
 Specifying a `ServiceAccount` to access a private `git` repository:
 ```yaml
 apiVersion: build.knative.dev/v1alpha1
 kind: Build
 metadata:
  name: test-build-with-serviceaccount-git-ssh
  labels:
    expect: succeeded
 spec:
  serviceAccountName: test-build-robot-git-ssh
  source:
    git:
      url: git@github.com:knative/build.git
      revision: master
  steps:
    - name: config
      image: ubuntu
      command: ["/bin/bash"]
      args: ["-c", "cat README.md"]
 ```
 Where `serviceAccountName: test-build-robot-git-ssh` references the following
 `ServiceAccount`:
 ```yaml
 apiVersion: v1
 kind: ServiceAccount
 metadata:
  name: test-build-robot-git-ssh
 secrets:
  - name: test-git-ssh
 ```
 And `name: test-git-ssh`, references the following `Secret`:
 ```yaml
 apiVersion: v1
 kind: Secret
 metadata:
  name: test-git-ssh
  annotations:
    build.knative.dev/git-0: github.com
 type: kubernetes.io/ssh-auth
 data:
  # Generated by:
  # cat id_rsa | base64 -w 0
  ssh-privatekey: LS0tLS1CRUdJTiBSU0EgUFJJVk.....[example]
  # Generated by:
  # ssh-keyscan github.com | base64 -w 0
  known_hosts: Z2l0aHViLmNvbSBzc2g.....[example]
 ```
 Note: For a working copy of this `ServiceAccount` example, see the
 [build/test/git-ssh](https://github.com/knative/build/tree/master/test/git-ssh)
 code sample.
 #### Using `timeout`
 Specifying `timeout` for your `build`:
 ```yaml
 spec:
  timeout: 20m
  source:
    git:
      url: https://github.com/knative/build.git
      revision: master
  steps:
    - image: ubuntu
      args: ["cat", "README.md"]
 ```
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/build/creating-builds.md
+++ b/docs/build/creating-builds.md
@ -1,181 +0,0 @@
 ---
 title: "Creating a simple Knative build"
 linkTitle: "Creating a build"
 weight: 30
 type: "docs"
 ---
 Use this page to learn how to create and then run a simple build in Knative. In
 this topic, you create a Knative Build configuration file for a simple app,
 deploy that build to Knative, and then test that the build completes.
 The following demonstrates the process of deploying and then testing that the
 build completed successfully. This sample build uses a hello-world-type app that
 uses [busybox](https://docs.docker.com/samples/library/busybox/) to simply print
 "_hello build_".
 Tip: See the
 [build code samples](./builds.md#get-started-with-knative-build-samples) for
 examples of more complex builds, including code samples that use container
 images, authentication, and include multiple steps.
 ## Before you begin
 Before you can run a Knative Build, you must have Knative installed in your
 Kubernetes cluster, and it must include the Knative Build component:
 - For details about installing a new instance of Knative in your Kubernetes
  cluster, see [Installing Knative](../install/README.md).
 - If you have a component of Knative installed and running, you must
  [ensure that the Knative Build component is also installed](./installing-build-component.md).
 ## Creating and running a build
 1. Create a configuration file named `build.yaml` that includes the following
   code.
   This `Build` resource definition includes a single
   "[step](./builds.md#steps)" that performs the task of simply printing "_hello
   build_":
   ```yaml
   apiVersion: build.knative.dev/v1alpha1
   kind: Build
   metadata:
     name: hello-build
   spec:
     steps:
       - name: hello
         image: busybox
         args: ["echo", "hello", "build"]
   ```
   Notice that this definition specifies `kind` as a `Build`, and that the name
   of this `Build` resource is `hello-build`. For more information about
   defining build configuration files, See the
   [`Build` reference topic](./builds.md).
 1. Deploy the `build.yaml` configuration file and run the `hello-build` build on
   Knative by running the
   [`kubectl apply`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply)
   command:
   ```shell
   kubectl apply --filename build.yaml
   ```
   Response:
   ```shell
   build "hello-build" created
   ```
 1. Verify that the `hello-build` build resource has been created by running the
   [`kubectl get`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get)
   command:
   ```shell
   kubectl get builds
   ```
   Response:
   ```shell
   NAME          AGE
   hello-build   4s
   ```
 1. After the build is created, you can run the following
   [`kubectl get`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get)
   command to retrieve details about the `hello-build` build, specifically, in
   which cluster and pod the build is running:
   ```shell
   kubectl get build hello-build --output yaml
   ```
   Response:
   ```shell
   apiVersion: build.knative.dev/v1alpha1
   kind: Build
   ...
   status:
     builder: Cluster
     cluster:
       namespace: default
       podName: hello-build-jx4ql
     conditions:
     - state: Complete
       status: "True"
     stepStates:
     - terminated:
         reason: Completed
     - terminated:
         reason: Completed
   ```
   Notice that the values of `completed` indicate that the build was successful,
   and that `hello-build-jx4ql` is the pod where the build ran.
   Tip: You can also retrieve the `podName` by running the following command:
   ```shell
   kubectl get build hello-build --output jsonpath={.status.cluster.podName}
   ```
 1. Optional: Run the following
   [`kubectl get`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get)
   command to retrieve details about the `hello-build-[ID]` pod, including the
   name of the
   [Init container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/):
   ```shell
   kubectl get pod hello-build-[ID] --output yaml
   ```
   where `[ID]` is the suffix of your pod name, for example `hello-build-jx4ql`.
   The response of this command includes a lot of detail, as well as the
   `build-step-hello` name of the Init container.
   Tip: The name of the Init container is determined by the `name` that is
   specified in the `steps` field of the build configuration file, for example
   `build-step-[ID]`.
 1. To verify that your build performed the single task of printing "_hello
   build_", you can run the
   [`kubectl logs`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs)
   command to retrieve the log files from the `build-step-hello` Init container
   in the `hello-build-[ID]` pod:
   ```shell
   kubectl logs $(kubectl get build hello-build --output jsonpath={.status.cluster.podName}) --container build-step-hello
   ```
   Response:
   ```shell
   hello build
   ```
 ### Learn more
 To learn more about the objects and commands used in this topic, see:
 - [Knative `Build` resources](./builds.md)
 - [Kubernetes Init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)
 - [Kubernetes kubectl CLI](https://kubernetes.io/docs/reference/kubectl/kubectl/)
 For information about contributing to the Knative Build project, see the
 [Knative Build code repo](https://github.com/knative/build/).
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/build/installing-build-component.md
+++ b/docs/build/installing-build-component.md
@ -1,55 +0,0 @@
 ---
 title: "Installing the Knative Build component"
 #linkTitle: "OPTIONAL_ALTERNATE_NAV_TITLE"
 weight: 10
 type: "docs"
 ---
 Before you can run a Knative Build, you must install the Knative Build component
 in your Kubernetes cluster. Use this page to add the Knative Build component to
 an existing Knative installation.
 You have the option to install and use only the components of Knative that you
 want, for example Knative serving is not required to create and run builds.
 ## Before you begin
 You must have a component of Knative installed and running in your Kubernetes
 cluster. For complete installation instructions, including how to install the
 Knative Build component, see [Installing Knative](../install/README.md).
 ## Adding the Knative Build component
 To add only the Knative Build component to an existing installation:
 1. Run the
   [`kubectl apply`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply)
   command to install [Knative Build](https://github.com/knative/build) and its
   dependencies:
   ```bash
   kubectl apply --filename https://github.com/knative/build/releases/download/v0.6.0/build.yaml
   ```
 1. Run the
   [`kubectl get`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get)
   command to monitor the Knative Build components until all of the components
   show a `STATUS` of `Running`:
   ```bash
   kubectl get pods --namespace knative-build
   ```
   Tip: Instead of running the `kubectl get` command multiple times, you can
   append the `--watch` flag to view the component's status updates in real
   time. Use CTRL + C to exit watch mode.
 You are now ready to create and run Knative Builds, see
 [Creating a simple Knative Build](./creating-builds.md) to get started.
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/build/personas.md
+++ b/docs/build/personas.md
@ -1,66 +0,0 @@
 ---
 title: "Knative personas"
 #linkTitle: "OPTIONAL_ALTERNATE_NAV_TITLE"
 weight: 20
 type: "docs"
 ---
 When discussing user actions, it is often helpful to
 [define specific user roles](<https://en.wikipedia.org/wiki/Persona_(user_experience)>)
 who might want to do the action.
 ## Knative Build
 We expect the build components of Knative to be useful on their own, as well as
 in conjunction with the compute components.
 ### Developer
 The developer personas for build are broader than the serverless workloads that
 the knative compute product focuses on. Developers expect to have build tools
 that integrate with their native language tooling for managing dependencies and
 even detecting language and runtime dependencies.
 User stories:
 - Start a build
 - Read build logs
 ### Language operator / contributor
 The language operators perform the work of integrating language tooling into the
 knative build system. This role can work either within a particular
 organization, or on behalf of a particular language runtime.
 User stories:
 - Create a build image / build pack
 - Enable build signing / provenance
 ## Contributors
 Contributors are an important part of the knative project. We always consider
 how infrastructure changes encourage and enable contributors to the project, as
 well as the impact on users.
 Types of users:
 - Hobbyist or newcomer
 - Motivated user
 - Corporate (employed) maintainer
 - Consultant
 User stories:
 - Check out the code
 - Build and run the code
 - Run tests
 - View test status
 - Run performance tests
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/build/samples.md
+++ b/docs/build/samples.md
@ -1,27 +0,0 @@
 ---
 title: "Knative Build code samples"
 linkTitle: "Code samples"
 weight: 90
 type: "docs"
 ---
 Use the following code samples to help you understand the various use cases for
 Knative Build. [Learn more about Knative Build](../index.html).
 [**See all Knative code samples**](../samples/)
 Use the following code samples to learn about configuring and createing your
 Knative Builds.
 Tip: Review and reference multiple samples to piece together more complex
 builds.
 #### Simple build samples
 - View the collection of code samples in the `knative/build` repo:
  [Simple test builds](https://github.com/knative/build/tree/master/test).
 #### Build template samples
 - View the collection of build templates in the `knative/build-template` repo:
  [Sample build templates](https://github.com/knative/build-templates).
--- a/docs/concepts/resources.md
+++ b/docs/concepts/resources.md
@ -21,59 +21,6 @@ community specifically for use with Knative.
 This section contains other tools and technologies that are useful when working
 with Knative.
 ### [`go-containerregistry`](https://github.com/google/go-containerregistry/)
 `go-containerregistry` is a Go library used by `ko`, `kaniko`, `skaffold` and
 others, which enables support for pushing, pulling and managing images in a
 container image registry, without requiring Docker to be installed.
 It also provides packages to interact with images in a local Docker daemon,
 which does require that Docker be installed.
 This library also provides a CLI tool called
 [`crane`](https://github.com/google/go-containerregistry/blob/master/cmd/crane/doc/crane.md),
 which can be used to interact with and inspect images in a registry.
 ### [`jib`](https://github.com/GoogleContainerTools/jib)
 `jib` is a tool, packaged as a Maven plugin and a Gradle plugin, that
 efficiently builds container images from Java source, without a Dockerfile,
 without requiring access to the Docker daemon.
 Like `ko`, when `jib` is invoked, it builds your Java source and pushes an image
 with that built source atop a
 [distroless](https://github.com/GoogleContainerTools/distroless) base image to
 produce small images that support fast incremental image builds.
 There are `BuildTemplate`s that wraps `jib` for use with Maven and Gradle, at
 https://github.com/knative/build-templates/blob/master/jib/. It expects that
 your `pom.xml` or `build.gradle` describes to `jib` where to push your image.
 The build templates take no parameters.
 ### [`kaniko`](https://github.com/GoogleContainerTools/kaniko)
 `kaniko` is a tool that enables building a container image from source using the
 Dockerfile format, without requiring access to a Docker daemon. Removing this
 requirement means that `kaniko` is
 [safe to run on a Kubernetes cluster](https://github.com/kubernetes/kubernetes/issues/1806).
 By contrast, building an image using `docker build` necessarily requires the
 Docker daemon, which would give the build complete access to your entire
 cluster. So that's a very bad idea.
 `kaniko` expects to run inside a container, so it's a natural fit for the Build
 CRD [builder contract](../build/builder-contract.md). `kaniko` is available as a
 builder at `gcr.io/kaniko-project/executor:latest`, and there's a
 `BuildTemplate` that wraps it at
 https://github.com/knative/build-templates/blob/master/kaniko/kaniko.yaml. It
 exposes one required parameter, `IMAGE`, which describes the name of the image
 to push to.
 More information here:
 https://github.com/knative/build-templates/tree/master/kaniko
 `kaniko` is unrelated to `ko`.
 ### [`ko`](https://github.com/google/ko)
 `ko` is a tool designed to make development of Go apps on Kubernetes easier, by
@ -119,16 +66,3 @@ image: gcr.io/my-docker-repo/foo-zyxwvut@sha256:abcdef # image by digest
 `ko` is used during development and release of Knative components, but is not
 intended to be required for _users_ of Knative -- they should only need to
 `kubectl apply` released configs generated by `ko`.
 ### [`skaffold`](https://github.com/GoogleContainerTools/skaffold)
 `skaffold` is a CLI tool to aid in iterative development for Kubernetes.
 Typically, you would write a
 [YAML config](https://github.com/GoogleContainerTools/skaffold/blob/master/examples/annotated-skaffold.yaml)
 describing to Skaffold how to build and deploy your app, then run
 `skaffold dev`, which will watch your local source tree for changes and
 continuously builds and deploys based on your config when changes are detected.
 Skaffold supports many pluggable implementations for building and deploying.
 Skaffold contributors are working on support for Knative Build as a build
 plugin, and could support Knative Serving as a deployment plugin.
--- a/docs/eventing/README.md
+++ b/docs/eventing/README.md
@ -350,9 +350,4 @@ example.
 - [Default Channels](./channels/default-channels.md) provide a way to choose the
  persistence strategy for Channels across the cluster.
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/install/Knative-custom-install.md
+++ b/docs/install/Knative-custom-install.md
@ -79,14 +79,12 @@ The following Knative installation files are available:
  - https://github.com/knative/serving/releases/download/v0.7.0/monitoring-tracing-jaeger-in-mem.yaml
  - https://github.com/knative/serving/releases/download/v0.7.0/monitoring-tracing-zipkin.yaml
  - https://github.com/knative/serving/releases/download/v0.7.0/monitoring-tracing-zipkin-in-mem.yaml
 - **Build Component**:
  - https://github.com/knative/build/releases/download/v0.7.0/build.yaml
 - **Eventing Component**:
  - https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml
  - https://github.com/knative/eventing/releases/download/v0.7.0/eventing.yaml
  - https://github.com/knative/eventing/releases/download/v0.7.0/in-memory-channel.yaml
  - https://github.com/knative/eventing/releases/download/v0.7.0/kafka.yaml
- **Eventing sources**:
+- **Eventing Resources**:
  - https://github.com/knative/eventing-contrib/releases/download/v0.7.0/github.yaml
  - https://github.com/knative/eventing-contrib/releases/download/v0.7.0/camel.yaml
  - https://github.com/knative/eventing-contrib/releases/download/v0.7.0/gcppubsub.yaml
@ -98,9 +96,8 @@ The following table includes details about the available Knative installation
 files from the Knative repositories:
 - [Serving][1]
 - [Build][3]
 - [Eventing][4]
- [Eventing Sources][5]
+- [Eventing Resources][5]
 | Knative Install Filename                       | Notes                                                                                                                                                                  | Dependencies                                                                              |
 | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
@ -113,8 +110,6 @@ files from the Knative repositories:
 | [`monitoring-tracing-jaeger-in-mem.yaml`][1.6] | Installs only [Jaeger in-memory][2.4]**\***                                                                                                                            | Serving component, [Jaeger Operator][2.5]                                                 |
 | [`monitoring-tracing-zipkin.yaml`][1.7]        | Installs only [Zipkin][2.3].**\***                                                                                                                                     | Serving component, ELK stack (monitoring-logs-elasticsearch.yaml)                         |
 | [`monitoring-tracing-zipkin-in-mem.yaml`][1.8] | Installs only [Zipkin in-memory][2.3]**\***                                                                                                                            | Serving component                                                                         |
 | **knative/build**                              |                                                                                                                                                                        |                                                                                           |
 | [`build.yaml`][3.1]†                           | Installs the Build component.                                                                                                                                          |                                                                                           |
 | **knative/eventing**                           |                                                                                                                                                                        |                                                                                           |
 | [`release.yaml`][4.1]†                         | Installs the Eventing component. Includes [ContainerSource](../eventing#containersource), [CronJobSource][6.2], the in-memory channel provisioner.                     |                                                                                           |
 | [`eventing.yaml`][4.2]                         | Installs the Eventing component. Includes [ContainerSource](../eventing#containersource) and [CronJobSource][6.2]. Does not include the in-memory channel provisioner. |                                                                                           |
@ -160,8 +155,6 @@ for details about installing the various supported observability plugins.
 [2.3]: https://zipkin.io/
 [2.4]: https://jaegertracing.io/
 [2.5]: https://github.com/jaegertracing/jaeger-operator#installing-the-operator
 [3]: https://github.com/knative/build/releases/tag/v0.7.0
 [3.1]: https://github.com/knative/build/releases/download/v0.7.0/build.yaml
 [4]: https://github.com/knative/eventing/releases/tag/v0.7.0
 [4.1]: https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml
 [4.2]:
@ -256,7 +249,6 @@ commands below.
      `[FILE_URL]`Examples:
      - `https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml --selector networking.knative.dev/certificate-provider!=cert-manager`
      - `https://github.com/knative/build/releases/download/v0.7.0/build.yaml`
      - `https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml`
      - `https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml`
@ -303,7 +295,6 @@ commands below.
        ```bash
        kubectl apply --selector knative.dev/crd-install=true \
          --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml \
          --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
          --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml
        ```
@ -313,7 +304,6 @@ commands below.
        ```bash
        kubectl apply --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml \
          --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
          --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml
        ```
@ -324,7 +314,6 @@ commands below.
   ```bash
   kubectl get pods --namespace knative-serving
   kubectl get pods --namespace knative-build
   kubectl get pods --namespace knative-eventing
   ```
@ -342,7 +331,7 @@ commands below.
   [Installing logging, metrics, and traces](../serving/installing-logging-metrics-traces.md)
   for details about setting up the various supported observability plugins.
-You are now ready to deploy an app, run a build, or start sending and receiving
+You are now ready to deploy an app or start sending and receiving
 events in your Knative cluster.
 ## What's next
@ -354,17 +343,6 @@ guides to help you get started with Knative:
  - [Knative Serving sample apps](../serving/samples/README.md)
 - [Creating a simple Knative Build](../build/creating-builds.md)
  - [Knative Build templates](https://github.com/knative/build-templates)
 - [Knative Eventing overview](../eventing/README.md)
  - [Knative Eventing code samples](../eventing/samples/)
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/install/Knative-with-AKS.md
+++ b/docs/install/Knative-with-AKS.md
@ -184,7 +184,6 @@ your Knative installation, see
   ```bash
   kubectl apply --selector knative.dev/crd-install=true \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -196,7 +195,6 @@ your Knative installation, see
   ```bash
   kubectl apply --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml --selector networking.knative.dev/certificate-provider!=cert-manager \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -216,7 +214,6 @@ your Knative installation, see
   `Running`:
   ```bash
   kubectl get pods --namespace knative-serving
   kubectl get pods --namespace knative-build
   kubectl get pods --namespace knative-eventing
   kubectl get pods --namespace knative-monitoring
   ```
@ -233,9 +230,6 @@ guide.
 To get started with Knative Eventing, pick one of the
 [Eventing Samples](../eventing/samples/) to walk through.
 To get started with Knative Build, read the [Build README](../build/README.md),
 then choose a sample to walk through.
 ## Cleaning up
 Running a cluster costs money, so you might want to delete the cluster when
--- a/docs/install/Knative-with-Ambassador.md
+++ b/docs/install/Knative-with-Ambassador.md
@ -37,16 +37,14 @@ see Performing a Custom Knative Installation.
        kubectl apply -l knative.dev/crd-install=true \
        --filename https://github.com/knative/serving/releases/download/v0.7.1/serving.yaml \
-        --filename https://github.com/knative/build/releases/download/v0.7.1/build.yaml \
+                --filename https://github.com/knative/serving/releases/download/v0.7.1/monitoring.yaml
        --filename https://github.com/knative/serving/releases/download/v0.7.1/monitoring.yaml
 2.  To complete the install of Knative and it's dependencies, run the
    `kubectl apply` command again, this time without the
    `-l knative.dev/crd-install=true`:
        kubectl apply --filename https://github.com/knative/serving/releases/download/v0.7.1 serving.yaml --selector networking.knative.dev/certificate-provider!=cert-manager \
-        --filename https://github.com/knative/build/releases/download/v0.7.1/build.yaml \
+                --filename https://github.com/knative/serving/releases/download/v0.7.1/monitoring.yaml
        --filename https://github.com/knative/serving/releases/download/v0.7.1/monitoring.yaml
    > **Notes**:
    >
--- a/docs/install/Knative-with-Docker-for-Mac.md
+++ b/docs/install/Knative-with-Docker-for-Mac.md
@ -128,9 +128,4 @@ To reset only the Kubernetes cluster to a fresh one, click "Reset Kubernetes
 cluster" in the
 [_Reset_ preferences](https://docs.docker.com/docker-for-mac/#reset).
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/install/Knative-with-GKE.md
+++ b/docs/install/Knative-with-GKE.md
@ -161,7 +161,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```bash
   kubectl apply --selector knative.dev/crd-install=true \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -172,7 +171,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```bash
   kubectl apply --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml --selector networking.knative.dev/certificate-provider!=cert-manager \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -193,7 +191,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```bash
   kubectl get pods --namespace knative-serving
   kubectl get pods --namespace knative-build
   kubectl get pods --namespace knative-eventing
   kubectl get pods --namespace knative-monitoring
   ```
@ -210,9 +207,6 @@ guide.
 To get started with Knative Eventing, pick one of the
 [Eventing Samples](../eventing/samples/) to walk through.
 To get started with Knative Build, read the [Build README](../build/README.md),
 then choose a sample to walk through.
 ## Cleaning up
 Running a cluster in Kubernetes Engine costs money, so you might want to delete
@ -224,10 +218,3 @@ To delete the cluster, enter the following command:
 ```bash
 gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_ZONE
 ```
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/install/Knative-with-Gardener.md
+++ b/docs/install/Knative-with-Gardener.md
@ -116,7 +116,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```bash
   kubectl apply --selector knative.dev/crd-install=true \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -127,7 +126,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```bash
   kubectl apply --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml --selector networking.knative.dev/certificate-provider!=cert-manager \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -147,7 +145,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   `Running`:
   ```bash
   kubectl get pods --namespace knative-serving
   kubectl get pods --namespace knative-build
   kubectl get pods --namespace knative-eventing
   kubectl get pods --namespace knative-monitoring
   ```
@ -195,9 +192,6 @@ guide.
 To get started with Knative Eventing, pick one of the
 [Eventing Samples](../eventing/samples/) to walk through.
 To get started with Knative Build, read the [Build README](../build/README.md),
 then choose a sample to walk through.
 ## Cleaning up
 Use the Gardener dashboard to delete your cluster, or execute the following with
@ -208,10 +202,3 @@ kubectl --kubeconfig garden-my-project.yaml --namespace garden--my-project annot
 kubectl --kubeconfig garden-my-project.yaml --namespace garden--my-project delete shoot my-cluster
 ```
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/install/Knative-with-ICP.md
+++ b/docs/install/Knative-with-ICP.md
@ -256,9 +256,4 @@ curl -L https://github.com/knative/serving/releases/download/v0.7.0/monitoring.y
 | kubectl delete --filename -
 ```
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/install/Knative-with-IKS.md
+++ b/docs/install/Knative-with-IKS.md
@ -200,7 +200,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```bash
   kubectl apply --selector knative.dev/crd-install=true \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -211,7 +210,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```bash
   kubectl apply --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml --selector networking.knative.dev/certificate-provider!=cert-manager \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -231,7 +229,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   `Running`:
   ```bash
   kubectl get pods --namespace knative-serving
   kubectl get pods --namespace knative-build
   kubectl get pods --namespace knative-eventing
   kubectl get pods --namespace knative-monitoring
   ```
@ -248,9 +245,6 @@ guide.
 To get started with Knative Eventing, pick one of the
 [Eventing Samples](../eventing/samples/) to walk through.
 To get started with Knative Build, read the [Build README](../build/README.md),
 then choose a sample to walk through.
 ## Cleaning up
 Running a cluster in IKS costs money, so if you're not using it, you might want
@ -262,10 +256,3 @@ To delete the cluster, enter the following command:
 ```bash
 ibmcloud cs cluster-rm $CLUSTER_NAME
 ```
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/install/Knative-with-Minikube.md
+++ b/docs/install/Knative-with-Minikube.md
@ -124,7 +124,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```shell
   kubectl apply --selector knative.dev/crd-install=true \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -135,7 +134,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```shell
   kubectl apply --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml --selector networking.knative.dev/certificate-provider!=cert-manager \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -156,7 +154,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```shell
   kubectl get pods --namespace knative-serving
   kubectl get pods --namespace knative-build
   kubectl get pods --namespace knative-eventing
   kubectl get pods --namespace knative-monitoring
   ```
@ -199,10 +196,3 @@ Delete the Kubernetes cluster along with Knative, Istio, and any deployed apps:
 ```shell
 minikube delete
 ```
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/install/Knative-with-OpenShift.md
+++ b/docs/install/Knative-with-OpenShift.md
@ -125,9 +125,4 @@ export IP_ADDRESS=$(oc get node  -o 'jsonpath={.items[0].status.addresses[0].add
 6. Click **Remove**.
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/install/Knative-with-PKS.md
+++ b/docs/install/Knative-with-PKS.md
@ -102,7 +102,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```bash
   kubectl apply --selector knative.dev/crd-install=true \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -113,7 +112,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   ```bash
   kubectl apply --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml --selector networking.knative.dev/certificate-provider!=cert-manager \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -133,7 +131,6 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
   `Running`:
   ```bash
   kubectl get pods --namespace knative-serving
   kubectl get pods --namespace knative-build
   kubectl get pods --namespace knative-eventing
   kubectl get pods --namespace knative-monitoring
   ```
@ -150,9 +147,6 @@ guide.
 To get started with Knative Eventing, pick one of the
 [Eventing Samples](../eventing/samples/) to walk through.
 To get started with Knative Build, read the [Build README](../build/README.md),
 then choose a sample to walk through.
 ## Cleaning up
 To delete the cluster, follow the documentation at
--- a/docs/install/Knative-with-any-k8s.md
+++ b/docs/install/Knative-with-any-k8s.md
@ -69,7 +69,6 @@ your Knative installation, see
   ```bash
   kubectl apply --selector knative.dev/crd-install=true \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -80,7 +79,6 @@ your Knative installation, see
   ```bash
   kubectl apply --filename https://github.com/knative/serving/releases/download/v0.7.0/serving.yaml --selector networking.knative.dev/certificate-provider!=cert-manager \
   --filename https://github.com/knative/build/releases/download/v0.7.0/build.yaml \
   --filename https://github.com/knative/eventing/releases/download/v0.7.0/release.yaml \
   --filename https://github.com/knative/serving/releases/download/v0.7.0/monitoring.yaml
   ```
@ -101,7 +99,6 @@ your Knative installation, see
   ```bash
   kubectl get pods --namespace knative-serving
   kubectl get pods --namespace knative-build
   kubectl get pods --namespace knative-eventing
   kubectl get pods --namespace knative-monitoring
   ```
@ -117,13 +114,3 @@ guide.
 To get started with Knative Eventing, pick one of the
 [Eventing Samples](../eventing/samples/) to walk through.
 To get started with Knative Build, read the [Build README](../build/README.md),
 then choose a sample to walk through.
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/install/README.md
+++ b/docs/install/README.md
@ -1,3 +1,4 @@
 Follow this guide to install Knative components on a platform of your choice.
 ## Choosing a Kubernetes cluster
@ -140,9 +141,4 @@ and set up an Istio IP range for outbound network access:
 - [Checking the version of your Knative Serving installation](./check-install-version.md)
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/reference/README.md
+++ b/docs/reference/README.md
@ -10,7 +10,6 @@ at [**www.knative.dev**](https://www.knative.dev/docs/reference/).
 The API source files are located at:
 - [Serving API](./serving.md)
 - [Build API](./build.md)
 - [Eventing API](./eventing/eventing.md)
 - [Eventing-contrib resources API](./eventing/eventing-resources.md)
@ -58,7 +57,6 @@ To generate a version of the API:
 1. Locate the commits or tags that correspond to the version of the API that you
   want to generate:
   - [Build](https://github.com/knative/build/releases/)
   - [Eventing](https://github.com/knative/eventing/releases/)
   - [Eventing-contrib resources](https://github.com/knative/eventing-contrib/releases/)
   - [Serving](https://github.com/knative/serving/releases/)
@ -68,7 +66,6 @@ To generate a version of the API:
   variables (`KNATIVE_[component_name]_COMMIT`):
   ```
   KNATIVE_BUILD_COMMIT=[commit_or_tag] \
   KNATIVE_EVENTING_COMMIT=[commit_or_tag] \
   KNATIVE_EVENTING_SOURCES_COMMIT=[commit_or_tag] \
   KNATIVE_SERVING_COMMIT=[commit_or_tag] \
@ -111,7 +108,6 @@ Using tags from each repo, you would run the following command to generate the
 v0.3.0 API source files:
 ```
 KNATIVE_BUILD_COMMIT=v0.3.0 \
 KNATIVE_EVENTING_COMMIT=v0.3.0 \
 KNATIVE_EVENTING_SOURCES_COMMIT=v0.3.0 \
 KNATIVE_SERVING_COMMIT=v0.3.0 \
--- a/docs/reference/build-api.md
+++ b/docs/reference/build-api.md
@ -1,8 +0,0 @@
 ---
 title: "Knative Build Component"
 linkTitle: "Build API"
 weight: 20
 type: "docs"
 ---
 {{< readfile file="build.md" relative="true" >}}
--- a/docs/reference/build.md
+++ b/docs/reference/build.md
--- a/docs/samples.md
+++ b/docs/samples.md
@ -15,7 +15,6 @@ closer with your goals.
 View the set of Knative code samples that are actively tested and maintained:
 - [Build code samples](./build/samples.md)
 - [Eventing and Eventing Sources code samples](./eventing/samples/)
 - [Serving code samples](./serving/samples/README.md)
--- a/docs/serving/README.md
+++ b/docs/serving/README.md
@ -90,9 +90,4 @@ in the Knative Serving repository.
 See the [Knative Serving Issues](https://github.com/knative/serving/issues) page
 for a full list of known issues.
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/accessing-logs.md
+++ b/docs/serving/accessing-logs.md
@ -107,31 +107,6 @@ kubectl get revisions
 kubernetes.labels.serving_knative_dev\/revision: <REVISION_NAME>
 ```
 ### Accessing build logs
 To access logs for a [Knative Build](../build/README.md):
 - Find the build's name in the specified in the `.yaml` file:
  ```yaml
  apiVersion: build.knative.dev/v1alpha1
  kind: Build
  metadata:
    name: <BUILD_NAME>
  ```
  Or find build names with the following command:
  ```
  kubectl get builds
  ```
 - Replace `<BUILD_NAME>` and enter the following search query in Kibana:
 ```
 kubernetes.labels.build\-name: <BUILD_NAME>
 ```
 ### Accessing end to end request traces
 See [Accessing Traces](./accessing-traces.md) page for details.
@ -142,9 +117,4 @@ Go to the
 [GCP Console logging page](https://console.cloud.google.com/logs/viewer) for
 your GCP project, which stores your logs via Stackdriver.
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/accessing-metrics.md
+++ b/docs/serving/accessing-metrics.md
@ -79,9 +79,4 @@ discovery issues for metrics.
 - To see a specific metric you can search for in the in search box on the top of
  the page
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/accessing-traces.md
+++ b/docs/serving/accessing-traces.md
@ -56,9 +56,4 @@ In order to access request traces, you use the Jaeger visualization tool.
 <!--TODO: Consider adding a video here. -->
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/debugging-application-issues.md
+++ b/docs/serving/debugging-application-issues.md
@ -146,14 +146,10 @@ If you see this condition, check the following to continue debugging:
 - [Check application logs](#check-application-logs)
 - [Check Istio routing](#check-clusteringressistio-routing)
-If you see other conditions, to debug further:
+If you see other conditions, look up the meaning of the conditions in Knative
-
+[Error Conditions and Reporting](https://github.com/knative/serving/blob/master/docs/spec/errors.md).
- Look up the meaning of the conditions in Knative
+Note: some of them are not implemented yet. An alternative is to
-  [Error Conditions and Reporting](https://github.com/knative/serving/blob/master/docs/spec/errors.md).
+[check Pod status](#check-pod-status).
  Note: some of them are not implemented yet. An alternative is to
  [check Pod status](#check-pod-status).
 - If you are using `BUILD` to deploy and the `BuildComplete` condition is not
  `True`, [check BUILD status](#check-build-status).
 ## Check Pod status
@ -181,31 +177,3 @@ kubectl get pod <pod-name> --output yaml
 If you see issues with "user-container" container in the containerStatuses,
 check your application logs as described below.
 ## Check Build status
 If you are using Build to deploy, run the following command to get the Build for
 your `Revision`:
 ```shell
 kubectl get build $(kubectl get revision <revision-name> --output jsonpath="{.spec.buildName}") --output yaml
 ```
 If there is any failure, the `conditions` in `status` provide the reason. To
 access build logs, first execute `kubectl proxy` and then open
 [Kibana UI](http://localhost:8001/api/v1/namespaces/knative-monitoring/services/kibana-logging/proxy/app/kibana).
 Use any of the following filters within Kibana UI to see build logs. For more
 information about the Knative observability features, see
 [Installing logging, metrics, and traces](./Installing-logging-metrics-traces.md).
 - All build logs: `_exists_:"kubernetes.labels.build-name"`
 - Build logs for a specific build: `kubernetes.labels.build-name:"<BUILD NAME>"`
 - Build logs for a specific build and step:
  `kubernetes.labels.build-name:"<BUILD NAME>" AND kubernetes.container_name:"build-step-<BUILD STEP NAME>"`
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/debugging-performance-issues.md
+++ b/docs/serving/debugging-performance-issues.md
@ -120,9 +120,4 @@ usage.
 ...To be filled...
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/getting-started-knative-app.md
+++ b/docs/serving/getting-started-knative-app.md
@ -1,8 +1,10 @@
 ---
 title: "Getting Started with App Deployment"
-#linkTitle: "OPTIONAL_ALTERNATE_NAV_TITLE"
+linkTitle: "Getting started"
-weight: 05
+weight: 01
 type: "docs"
 aliases:
  - "/docs/install/getting-started-knative-app/"
 ---
 This guide shows you how to deploy an app using Knative, then interact with it
@ -181,10 +183,3 @@ To remove the sample app from your cluster, delete the service record:
 ```shell
 kubectl delete --filename service.yaml
 ```
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/gke-assigning-static-ip-address.md
+++ b/docs/serving/gke-assigning-static-ip-address.md
@ -101,9 +101,4 @@ xxxxxxx-ingressgateway   LoadBalancer   12.34.567.890   98.765.43.210   80:32380
 > Note: Updating the external IP address can take several minutes.
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/installing-logging-metrics-traces.md
+++ b/docs/serving/installing-logging-metrics-traces.md
@ -333,9 +333,4 @@ end traces.
  - [Accessing Metrics](./accessing-metrics.md)
  - [Accessing Traces](./accessing-traces.md)
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/outbound-network-access.md
+++ b/docs/serving/outbound-network-access.md
@ -101,9 +101,4 @@ metadata:
 ...
 ```
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/setting-up-a-logging-plugin.md
+++ b/docs/serving/setting-up-a-logging-plugin.md
@ -87,9 +87,4 @@ To uninstall a logging plugin, run:
 kubectl delete --recursive --filename <path-of-fluentd-daemonset-config>
 ```
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/using-a-custom-domain.md
+++ b/docs/serving/using-a-custom-domain.md
@ -177,9 +177,4 @@ Once the domain update has propagated, you can access your app using the fully
 qualified domain name of the deployed route, for example
 `http://helloworld-go.default.mydomain.com`
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/docs/serving/using-a-tls-cert.md
+++ b/docs/serving/using-a-tls-cert.md
@ -226,9 +226,4 @@ Kubernetes secret and then configure the `knative-ingress-gateway`:
 After your changes are running on your Knative cluster, you can begin using the
 HTTPS protocol for secure access your deployed Knative services.
 ---
 Except as otherwise noted, the content of this page is licensed under the
 [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the
 [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
--- a/hack/gen-api-reference-docs.sh
+++ b/hack/gen-api-reference-docs.sh
@ -29,10 +29,6 @@ KNATIVE_SERVING_REPO="github.com/knative/serving"
 KNATIVE_SERVING_COMMIT="${KNATIVE_SERVING_COMMIT:?specify the \$KNATIVE_SERVING_COMMIT variable}"
 KNATIVE_SERVING_OUT_FILE="serving.md"
 KNATIVE_BUILD_REPO="github.com/knative/build"
 KNATIVE_BUILD_COMMIT="${KNATIVE_BUILD_COMMIT:?specify the \$KNATIVE_BUILD_COMMIT variable}"
 KNATIVE_BUILD_OUT_FILE="build.md"
 KNATIVE_EVENTING_REPO="github.com/knative/eventing"
 KNATIVE_EVENTING_COMMIT="${KNATIVE_EVENTING_COMMIT:?specify the \$KNATIVE_EVENTING_COMMIT variable}"
 KNATIVE_EVENTING_OUT_FILE="eventing/eventing.md"
@ -160,13 +156,6 @@ main() {
    gen_refdocs "${refdocs_bin}" "${clone_root}" "${template_dir}" \
        "${out_dir}/${KNATIVE_SERVING_OUT_FILE}" "${knative_serving_root}" "./pkg/apis"
    local knative_build_root
    knative_build_root="${clone_root}/src/${KNATIVE_BUILD_REPO}"
    clone_at_commit "https://${KNATIVE_BUILD_REPO}.git" "${KNATIVE_BUILD_COMMIT}" \
        "${knative_build_root}"
    gen_refdocs "${refdocs_bin}" "${clone_root}" "${template_dir}" \
        "${out_dir}/${KNATIVE_BUILD_OUT_FILE}" "${knative_build_root}" "./pkg/apis"
    local knative_eventing_root
    knative_eventing_root="${clone_root}/src/${KNATIVE_EVENTING_REPO}"
    clone_at_commit "https://${KNATIVE_EVENTING_REPO}.git" "${KNATIVE_EVENTING_COMMIT}" \