fix build links (#858)

This commit is contained in:
RichieEscarez 2019-02-01 18:03:58 -08:00 committed by Richie Escarez
parent 59218e0f29
commit 847e08bf2e
6 changed files with 20 additions and 20 deletions

10
docs/build/README.md vendored
View File

@ -35,10 +35,10 @@ More information about this use case is demonstrated in
See the following reference topics for information about each of the build See the following reference topics for information about each of the build
components: components:
- [`Build`](https://github.com/knative/docs/blob/master/build/builds.md) - [`Build`](builds/)
- [`BuildTemplate`](https://github.com/knative/docs/blob/master/build/build-templates.md) - [`BuildTemplate`](build-templates/)
- [`Builder`](https://github.com/knative/docs/blob/master/build/builder-contract.md) - [`Builder`](builder-contract/)
- [`ServiceAccount`](https://github.com/knative/docs/blob/master/build/auth.md) - [`ServiceAccount`](auth/)
## Install the Knative Build component ## Install the Knative Build component
@ -52,7 +52,7 @@ in your Kubernetes cluster:
cluster, see [Installing Knative](../install/). cluster, see [Installing Knative](../install/).
- If you have a component of Knative installed and running, you can - If you have a component of Knative installed and running, you can
[add and install the Knative Build component](installing-build-component.md). [add and install the Knative Build component](installing-build-component/).
## Configuration syntax example ## Configuration syntax example

View File

@ -84,7 +84,7 @@ 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 graduated complexity, where options are overridden only when the user strays
from some set of sane defaults. from some set of sane defaults.
The `steps` and `volumes` parameters are just like in a [`Build`](./builds.md) The `steps` and `volumes` parameters are just like in a [`Build`](./builds/)
resource, but might contain references to parameters in the form: resource, but might contain references to parameters in the form:
`${PARAMETER_NAME}`. `${PARAMETER_NAME}`.

View File

@ -68,7 +68,7 @@ Builders should expect a Build to implement the following conventions:
- `/builder/home`: This volume is exposed to steps via `$HOME`. - `/builder/home`: This volume is exposed to steps via `$HOME`.
- Credentials attached to the Build's service account may be exposed as Git or - Credentials attached to the Build's service account may be exposed as Git or
Docker credentials as outlined [here](./auth.md). Docker credentials as outlined [here](./auth/).
--- ---

14
docs/build/builds.md vendored
View File

@ -96,7 +96,7 @@ The `steps` field is required if the `template` field is not defined. You define
one or more `steps` fields to define the body of a build. one or more `steps` fields to define the body of a build.
Each `steps` in a build must specify a `Builder`, or type of container image Each `steps` in a build must specify a `Builder`, or type of container image
that adheres to the [Knative builder contract](./builder-contract.md). For each that adheres to the [Knative builder contract](./builder-contract/). For each
of the `steps` fields, or container images that you define: of the `steps` fields, or container images that you define:
- The `Builder`-type container images are run and evaluated in order, starting - The `Builder`-type container images are run and evaluated in order, starting
@ -105,16 +105,16 @@ of the `steps` fields, or container images that you define:
detected. detected.
For details about how to ensure that you implement each step to align with the 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. "builder contract", see the [`Builder`](./builder-contract/) reference topic.
#### Template #### Template
The `template` field is a required if no `steps` are defined. Specifies a The `template` field is a required if no `steps` are defined. Specifies a
[`BuildTemplate`](./build-templates.md) resource object, in which includes [`BuildTemplate`](./build-templates/) resource object, in which includes
repeatable or sharable build `steps`. repeatable or sharable build `steps`.
For examples and more information about build templates, see the For examples and more information about build templates, see the
[`BuildTemplate`](./build-templates.md) reference topic. [`BuildTemplate`](./build-templates/) reference topic.
#### Source #### Source
@ -147,7 +147,7 @@ that is in the
of the `Build` resource object. of the `Build` resource object.
For examples and more information about specifying service accounts, see the For examples and more information about specifying service accounts, see the
[`ServiceAccount`](./auth.md) reference topic. [`ServiceAccount`](./auth/) reference topic.
#### Volumes #### Volumes
@ -155,11 +155,11 @@ Optional. Specifies one or more
[volumes](https://kubernetes.io/docs/concepts/storage/volumes/) that you want to [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 make available to your build, including all the build steps. Add volumes to
complement the volumes that are implicitly complement the volumes that are implicitly
[created during a build step](./builder-contract.md). [created during a build step](./builder-contract/).
For example, use volumes to accomplish one of the following common tasks: For example, use volumes to accomplish one of the following common tasks:
- [Mount a Kubernetes secret](./auth.md). - [Mount a Kubernetes secret](./auth/).
- Create an `emptyDir` volume to act as a cache for use across multiple build - Create an `emptyDir` volume to act as a cache for use across multiple build
steps. Consider using a persistent volume for inter-build caching. steps. Consider using a persistent volume for inter-build caching.

View File

@ -14,7 +14,7 @@ uses [busybox](https://docs.docker.com/samples/library/busybox/) to simply print
"_hello build_". "_hello build_".
Tip: See the Tip: See the
[build code samples](builds.md#get-started-with-knative-build-samples) for [build code samples](builds/#get-started-with-knative-build-samples) for
examples of more complex builds, including code samples that use container examples of more complex builds, including code samples that use container
images, authentication, and include multiple steps. images, authentication, and include multiple steps.
@ -27,14 +27,14 @@ Kubernetes cluster, and it must include the Knative Build component:
cluster, see [Installing Knative](../install/). cluster, see [Installing Knative](../install/).
- If you have a component of Knative installed and running, you must - 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). [ensure that the Knative Build component is also installed](installing-build-component/).
## Creating and running a build ## Creating and running a build
1. Create a configuration file named `build.yaml` that includes the following 1. Create a configuration file named `build.yaml` that includes the following
code. code.
This `Build` resource definition includes a single "[step](builds.md#steps)" This `Build` resource definition includes a single "[step](builds/#steps)"
that performs the task of simply printing "_hello build_": that performs the task of simply printing "_hello build_":
```yaml ```yaml
@ -52,7 +52,7 @@ Kubernetes cluster, and it must include the Knative Build component:
Notice that this definition specifies `kind` as a `Build`, and that the name Notice that this definition specifies `kind` as a `Build`, and that the name
of this `Build` resource is `hello-build`. For more information about of this `Build` resource is `hello-build`. For more information about
defining build configuration files, See the defining build configuration files, See the
[`Build` reference topic](builds.md). [`Build` reference topic](builds/).
1. Deploy the `build.yaml` configuration file and run the `hello-build` build on 1. Deploy the `build.yaml` configuration file and run the `hello-build` build on
Knative by running the Knative by running the
@ -164,7 +164,7 @@ Kubernetes cluster, and it must include the Knative Build component:
To learn more about the objects and commands used in this topic, see: To learn more about the objects and commands used in this topic, see:
- [Knative `Build` resources](builds.md) - [Knative `Build` resources](builds/)
- [Kubernetes Init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) - [Kubernetes Init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)
- [Kubernetes kubectl CLI](https://kubernetes.io/docs/reference/kubectl/kubectl/) - [Kubernetes kubectl CLI](https://kubernetes.io/docs/reference/kubectl/kubectl/)

View File

@ -42,7 +42,7 @@ To add only the Knative Build component to an existing installation:
time. Use CTRL + C to exit watch mode. time. Use CTRL + C to exit watch mode.
You are now ready to create and run Knative Builds, see You are now ready to create and run Knative Builds, see
[Creating a simple Knative Build](../build/creating-builds.md) to get started. [Creating a simple Knative Build](../build/creating-builds/) to get started.
--- ---