knative
/
docs
mirror of https://github.com/knative/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

remove knative build from everywhere (#1656)

This commit is contained in:
RichieEscarez 2019-08-08 08:42:56 -07:00 committed by Knative Prow Robot
parent bb824f1f97
commit e1a90c498b
45 changed files with 25 additions and 3151 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
community/samples/README.md
View File

@ -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 Sources samples
#### Eventing and Eventing Resources samples
- _Be the first to contribute an Eventing or Eventing Sources code sample to the
community collection._

13
docs/README.md
View File

@ -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).

96
docs/build/README.md vendored
View File

@ -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
[Kubernetes Custom Resource Definition (CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
The Knative Build component has been deprecated. For more information,
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
action, you can define a Knative `Build` through a single configuration file.
## 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).
Documentation for the final release of Knative Build is available in the
[**v0.7 docs release**](../v0.7-docs/build/).

8
docs/build/_index.md vendored
View File

@ -1,8 +1,8 @@
---
title: "Knative Build"
linkTitle: "Build Component"
weight: 20
title: "Deprecated: Knative Build Component"
linkTitle: "(Deprecated) Build"
weight: 200
type: "docs"
---
{{% readfile file="README.md" relative="true" markdown="true" %}}
{{% readfile file="README.md" %}}

402
docs/build/auth.md vendored
View File

@ -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).

164
docs/build/build-templates.md vendored
View File

@ -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).

79
docs/build/builder-contract.md vendored
View File

@ -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).

366
docs/build/builds.md vendored
View File

@ -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).

181
docs/build/creating-builds.md vendored
View File

@ -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).

55
docs/build/installing-build-component.md vendored
View File

@ -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).

66
docs/build/personas.md vendored
View File

@ -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).

27
docs/build/samples.md vendored
View File

@ -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).

66
docs/concepts/resources.md
View File

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

5
docs/eventing/README.md
View File

@ -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).

28
docs/install/Knative-custom-install.md
View File

@ -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).

6
docs/install/Knative-with-AKS.md
View File

@ -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

6
docs/install/Knative-with-Ambassador.md
View File

@ -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**:
>

5
docs/install/Knative-with-Docker-for-Mac.md
View File

@ -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).

13
docs/install/Knative-with-GKE.md
View File

@ -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).

13
docs/install/Knative-with-Gardener.md
View File

@ -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).

5
docs/install/Knative-with-ICP.md
View File

@ -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).

13
docs/install/Knative-with-IKS.md
View File

@ -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).

10
docs/install/Knative-with-Minikube.md
View File

@ -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).

5
docs/install/Knative-with-OpenShift.md
View File

@ -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).

6
docs/install/Knative-with-PKS.md
View File

@ -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

13
docs/install/Knative-with-any-k8s.md
View File

@ -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).

6
docs/install/README.md
View File

@ -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).

4
docs/reference/README.md
View File

@ -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 \

8
docs/reference/build-api.md
View File

@ -1,8 +0,0 @@
---
title: "Knative Build Component"
linkTitle: "Build API"
weight: 20
type: "docs"
---
{{< readfile file="build.md" relative="true" >}}

1357
docs/reference/build.md
View File

File diff suppressed because it is too large Load Diff

1
docs/samples.md
View File

@ -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)

5
docs/serving/README.md
View File

@ -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).

30
docs/serving/accessing-logs.md
View File

@ -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).

5
docs/serving/accessing-metrics.md
View File

@ -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).

5
docs/serving/accessing-traces.md
View File

@ -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).

40
docs/serving/debugging-application-issues.md
View File

@ -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:
- Look up the meaning of the conditions in Knative
[Error Conditions and Reporting](https://github.com/knative/serving/blob/master/docs/spec/errors.md).
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).
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).
Note: some of them are not implemented yet. An alternative is to
[check Pod status](#check-pod-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).

5
docs/serving/debugging-performance-issues.md
View File

@ -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).

13
docs/install/getting-started-knative-app.md → docs/serving/getting-started-knative-app.md
View File

@ -1,8 +1,10 @@
---
title: "Getting Started with App Deployment"
#linkTitle: "OPTIONAL_ALTERNATE_NAV_TITLE"
weight: 05
linkTitle: "Getting started"
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).

5
docs/serving/gke-assigning-static-ip-address.md
View File

@ -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).

5
docs/serving/installing-logging-metrics-traces.md
View File

@ -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).

5
docs/serving/outbound-network-access.md
View File

@ -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).

5
docs/serving/setting-up-a-logging-plugin.md
View File

@ -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).

5
docs/serving/using-a-custom-domain.md
View File

@ -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).

5
docs/serving/using-a-tls-cert.md
View File

@ -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).

11
hack/gen-api-reference-docs.sh
View File

@ -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}" \