include ci-yml in body

doc/user/project/clusters/index.md

@@ -227,7 +227,7 @@ twice, which can lead to confusion during deployments.
 | [Prometheus](https://prometheus.io/docs/introduction/overview/) | 10.4+ | Prometheus is an open-source monitoring and alerting system useful to supervise your deployed applications. | [stable/prometheus](https://github.com/helm/charts/tree/master/stable/prometheus) |
 | [GitLab Runner](https://docs.gitlab.com/runner/) | 10.6+ | GitLab Runner is the open source project that is used to run your jobs and send the results back to GitLab. It is used in conjunction with [GitLab CI/CD](https://about.gitlab.com/features/gitlab-ci-cd/), the open-source continuous integration service included with GitLab that coordinates the jobs. When installing the GitLab Runner via the applications, it will run in **privileged mode** by default. Make sure you read the [security implications](#security-implications) before doing so. | [runner/gitlab-runner](https://gitlab.com/charts/gitlab-runner) |
 | [JupyterHub](http://jupyter.org/) | 11.0+ | [JupyterHub](https://jupyterhub.readthedocs.io/en/stable/) is a multi-user service for managing notebooks across a team. [Jupyter Notebooks](https://jupyter-notebook.readthedocs.io/en/latest/) provide a web-based interactive programming environment used for data analysis, visualization, and machine learning. We use [this](https://gitlab.com/gitlab-org/jupyterhub-user-image/blob/master/Dockerfile) custom Jupyter image that installs additional useful packages on top of the base Jupyter. You will also see ready-to-use DevOps Runbooks built with Nurtch's [Rubix library](https://github.com/amit1rrr/rubix). More information on creating executable runbooks can be found at [Nurtch Documentation](http://docs.nurtch.com/en/latest).  **Note**: Authentication will be enabled for any user of the GitLab server via OAuth2. HTTPS will be supported in a future release. | [jupyter/jupyterhub](https://jupyterhub.github.io/helm-chart/) |
-| [Knative](https://cloud.google.com/knative) | 0.1.2 | Knative provides a platform to create, deploy, and manage serverless workloads from a Kubernetes cluster. It is used in conjunction with, and includes [Istio](https://istio.io) to provide an external IP address for all programs hosted by Knative. You will be prompted to enter a wildcard domain where your applications will be exposed. Configure your DNS server to use the external IP address for that domain. For any application created and installed, they will be accessible as <program_name>.<kubernetes_namespace>.<domain_name>.  **Note**: This will require your kubernetes cluster to have RBAC enabled. | [knative/knative](https://storage.googleapis.com/triggermesh-charts)
+| [Knative](https://cloud.google.com/knative) | 0.1.2 | Knative provides a platform to create, deploy, and manage serverless workloads from a Kubernetes cluster. It is used in conjunction with, and includes [Istio](https://istio.io) to provide an external IP address for all programs hosted by Knative. You will be prompted to enter a wildcard domain where your applications will be exposed. Configure your DNS server to use the external IP address for that domain. For any application created and installed, they will be accessible as `<program_name>.<kubernetes_namespace>.<domain_name>`.  **Note**: This will require your kubernetes cluster to have RBAC enabled. | [knative/knative](https://storage.googleapis.com/triggermesh-charts)
 
 ## Getting the external IP address
 
@@ -284,6 +284,7 @@ kubectl get svc --all-namespaces -o jsonpath='{range.items[?(@.status.loadBalanc
 ```
 
 > **Note**: Some Kubernetes clusters return a hostname instead, like [Amazon EKS](https://aws.amazon.com/eks/). For these platforms, run:
+
 > ```bash
 > kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps -o jsonpath="{.status.loadBalancer.ingress[0].hostname}".
 > ```

doc/user/project/clusters/serverless/index.md

@@ -22,15 +22,45 @@ To run Knative on Gitlab, you will need:
     The simplest way to get started is to add a cluster using [GitLab's GKE integration](https://docs.gitlab.com/ee/user/project/clusters/#adding-and-creating-a-new-gke-cluster-via-gitlab). 
     GitLab recommends 
 1. **Helm Tiller:** Helm is a package manager for Kubernetes and is required to install 
-    all the other applications. It is installed in its own pod inside the cluster which 
-    can run the helm CLI in a safe environment.
+    all the other applications.
 1. **Domain Name:** Knative will provide its own load balancer using Istio. It will provide an 
     external IP address for all the applications served by Knative. You will be prompted to enter a 
     wildcard domain where your applications will be served. Configure your DNS server to use the 
     external IP address for that domain.
-1. **Serverless `gitlab-ci.yml` Template:** GitLab uses the [TriggerMesh CLI](https://github.com/triggermesh/tm), 
-    a serverless resource management utilty to work with knative objects. The `gitlab-ci.yml` template uses it 
-    to build and deploy knative services and functions. [Access the template here](serverless_ci_yml_template.yml).
+1. **Serverless `gitlab-ci.yml` Template:** GitLab uses [Kaniko](https://github.com/GoogleContainerTools/kaniko) 
+    to build the application and the [TriggerMesh CLI](https://github.com/triggermesh/tm), to simplify the 
+    deployment of knative services and functions.
+
+    Add the following `.gitlab-ci.yml` to the root of your repository (you may skip this step if using the sample 
+    [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) mentioned below).
+
+    ```yaml
+    stages:
+    - build
+    - deploy
+
+    build:
+    stage: build
+    image:
+        name: gcr.io/kaniko-project/executor:debug
+        entrypoint: [""]
+    only:
+        - master
+    script:
+        - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
+        - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE
+
+    deploy:
+    stage: deploy
+    image: gcr.io/triggermesh/tm@sha256:e3ee74db94d215bd297738d93577481f3e4db38013326c90d57f873df7ab41d5
+    only:
+        - master
+    environment: production
+    script:
+        - echo "$CI_REGISTRY_IMAGE"
+        - tm -n "$KUBE_NAMESPACE" --config "$KUBECONFIG" deploy service "$CI_PROJECT_NAME" --from-image "$CI_REGISTRY_IMAGE" --wait
+    ```
+
 1. **Docker File:** Knative requires a docker file in order to build your application. It should be included 
     at the root of your project's repo.
 
@@ -54,16 +84,18 @@ You may download the sample [Knative Ruby App](https://gitlab.com/knative-exampl
     kubectl get svc --namespace=istio-system knative-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip} '
     ```
 
-1. The ingress is now available at this address and will route incoming requests to the proper service based on the DNS 
-    name in the request. To support this, a wildcard DNS A record should be created for the desired domain name.
-
-    ![dns entry](img/dns-entry.png)
+    Output:
 
-## Deploying the GitLab Runner (optional)
+    ```bash
+    35.161.143.124 my-machine-name:~ my-user$
+    ```
 
-If the project is on GitLab.com, free shared runners are available and you do not have to deploy one. If a project specific runner is desired, or there are no shared runners, it is easy to deploy one.
+1. The ingress is now available at this address and will route incoming requests to the proper service based on the DNS 
+    name in the request. To support this, a wildcard DNS A record should be created for the desired domain name. For example, 
+    if your Knative base domain is `knative.example.com` then you need to create an A record with domain `*.knative.example.com` 
+    pointing the ip address of the ingress.
 
-Simply click on the "**Install**" button for the GitLab Runner. It is important to note that the runner deployed is set as privileged, which means it essentially has root access to the underlying machine. This is required to build docker images, and so is on by default.
+    ![dns entry](img/dns-entry.png)
 
 ## Deploy the application with Knative
 

doc/user/project/clusters/serverless/serverless_ci_yml_template.yml

-stages:
-  - build
-  - deploy
-  
-variables:
-  DOCKER_DRIVER: overlay2
-
-build:
-  stage: build
-  image: docker:stable-git
-  services:
-  - docker:stable-dind
-  before_script:
-  - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
-  script:
-    - docker build --pull -t "$CI_REGISTRY_IMAGE" .
-    - docker push "$CI_REGISTRY_IMAGE"
-
-deploy:
-  stage: deploy
-  image: gcr.io/triggermesh/tm@sha256:e3ee74db94d215bd297738d93577481f3e4db38013326c90d57f873df7ab41d5
-  environment: production
-  script:
-    - echo "$CI_REGISTRY_IMAGE"
-    - tm -n "$KUBE_NAMESPACE" --config "$KUBECONFIG" deploy service "$CI_PROJECT_NAME" --from-image "$CI_REGISTRY_IMAGE" --wait