Update Build vendor (#1384)

* Update build vendor, fix tests

* Update build.dev references

* update commit

* Update build vendor, fix tests

* update commit

* update

* update build/release.yaml

* Update samples to use revision instead of branch

* update dep
This commit is contained in:
Jason Hall 2018-07-01 22:38:26 -04:00 committed by Google Prow Robot
parent 7aa1bdaf3b
commit a1b43fbe48
4 changed files with 6 additions and 6 deletions

View File

@ -242,7 +242,7 @@ For example, use these steps to allow Minikube to pull Knative Serving and Build
from GCR as published in our development flow (`ko apply -f config/`). from GCR as published in our development flow (`ko apply -f config/`).
_This is only necessary if you are not using public Knative Serving and Build images._ _This is only necessary if you are not using public Knative Serving and Build images._
1. Create a Kubernetes secret in the `knative-serving` and `build-system` namespace: 1. Create a Kubernetes secret in the `knative-serving` and `knative-build` namespace:
```shell ```shell
export DOCKER_EMAIL=your.email@here.com export DOCKER_EMAIL=your.email@here.com
@ -257,7 +257,7 @@ _This is only necessary if you are not using public Knative Serving and Build im
--docker-username=_json_key \ --docker-username=_json_key \
--docker-password="$(cat minikube-gcr-key.json)" \ --docker-password="$(cat minikube-gcr-key.json)" \
--docker-email=$DOCKER_EMAIL \ --docker-email=$DOCKER_EMAIL \
-n "build-system" -n "knative-build"
``` ```
_The secret must be created in the same namespace as the pod or service _The secret must be created in the same namespace as the pod or service
@ -269,7 +269,7 @@ _This is only necessary if you are not using public Knative Serving and Build im
```shell ```shell
kubectl patch serviceaccount "build-controller" \ kubectl patch serviceaccount "build-controller" \
-p '{"imagePullSecrets": [{"name": "build-gcr"}]}' \ -p '{"imagePullSecrets": [{"name": "build-gcr"}]}' \
-n "build-system" -n "knative-build"
kubectl patch serviceaccount "controller" \ kubectl patch serviceaccount "controller" \
-p '{"imagePullSecrets": [{"name": "knative-serving-gcr"}]}' \ -p '{"imagePullSecrets": [{"name": "knative-serving-gcr"}]}' \
-n "knative-serving" -n "knative-serving"

View File

@ -69,7 +69,7 @@ controller-5bfb798f96-2zjnf 1/1 Running 0 9m
webhook-64c459569b-v5npx 1/1 Running 0 8m webhook-64c459569b-v5npx 1/1 Running 0 8m
``` ```
Similarly, you can run the same commands in the build-crd (`build-system`) and istio (`istio-system`) namespaces to view the running deployments. To view all namespaces, run `kubectl get namespaces`. Similarly, you can run the same commands in the build-crd (`knative-build`) and istio (`istio-system`) namespaces to view the running deployments. To view all namespaces, run `kubectl get namespaces`.
### Service Accounts and RBAC policies ### Service Accounts and RBAC policies

View File

@ -158,7 +158,7 @@ Revision) should have a status field to link to the log output of the
build. build.
```http ```http
GET /apis/build.dev/v1alpha1/namespaces/default/builds/build-1acub3 GET /apis/build.knative.dev/v1alpha1/namespaces/default/builds/build-1acub3
``` ```
```yaml ```yaml

View File

@ -134,7 +134,7 @@ kubernetes.labels.build\-name: "test-build"
Replace `test-build` with your build's name. The build name is specified in the `.yaml` file as follows: Replace `test-build` with your build's name. The build name is specified in the `.yaml` file as follows:
```yaml ```yaml
apiVersion: build.dev/v1alpha1 apiVersion: build.knative.dev/v1alpha1
kind: Build kind: Build
metadata: metadata:
name: test-build name: test-build