Update tm cli version and clarify steps

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

@@ -82,7 +82,27 @@ Currently the following [runtimes](https://gitlab.com/triggermesh/runtimes) are
 - node.js
 - kaniko
 
-In order to deploy functions to your Knative instance, the following files must be present:
+You can find all the files referenced in this doc in the [functions example project](https://gitlab.com/knative-examples/functions).
+
+Follow these steps to deploy a function using the node.js runtime to your Knative instance:
+
+1. Create a directory that will house the function. In this example we will create a directory called `echo` at the root of the project.
+
+1. Create the file that will contain the function code. In this example our file is called `echo.js` and is located inside the `echo` directory.
+
+    If your project is public, skip to step no. 4.
+
+1. If your project is private you will need to [Create a GitLab deploy token](https://docs.gitlab.com/ee/user/project/deploy_tokens/#creating-a-deploy-token). 
+This will enable the `tm` cli to be used as a deployment step and access the container registry.
+
+    1. Go to the project you want to create the function for.
+    1. Go to **Settings** > **Repository**.
+    1. Click on "Expand" on **Deploy Tokens** section.
+    1. Enter `gitlab-deploy-token` as the name.
+    1. Check the `read_registry` scope
+    1. Click on **Create deploy token**.
+    1. Save the deploy token somewhere safe. Once you leave or refresh
+    the page, **you won't be able to access it again**.
 
 1. `.gitlab-ci.yml`: This template allows to define the stage, environment, and
    image to be used for your functions. It must be included at the root of your repository:
@@ -94,10 +114,12 @@ In order to deploy functions to your Knative instance, the following files must
    functions:
      stage: deploy
      environment: test
-     image: gcr.io/triggermesh/tm:v0.0.7
+     image: gcr.io/triggermesh/tm:v0.0.9
      script:
-       - tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_REGISTRY_USER" --password "$CI_JOB_TOKEN"
-       - tm -n "$KUBE_NAMESPACE" --registry-host "$CI_REGISTRY_IMAGE" deploy --wait
+        - tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_REGISTRY_USER" --password "$CI_JOB_TOKEN" --push
+        - tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_DEPLOY_USER" --password "$CI_DEPLOY_PASSWORD" --pull
+        - tm -n "$KUBE_NAMESPACE" deploy --wait
+
    ```
 
     The `gitlab-ci.yml` template creates a `Deploy` stage with a `functions` job that invokes the `tm` CLI with the required parameters.
@@ -127,7 +149,9 @@ In order to deploy functions to your Knative instance, the following files must
    ```
 
 
-The `serverless.yml` file is referencing both an `echo` directory (under `buildargs`) and an `echo` file (under `handler`) which is a reference to `echo.js` in the [repository](https://gitlab.com/knative-examples/functions). Additionally, it contains three sections with distinct parameters:
+The `serverless.yml` file is referencing both an `echo` directory (under `buildargs`) and an `echo` file (under `handler`) 
+which is a reference to `echo.js` in the [repository](https://gitlab.com/knative-examples/functions). Additionally, it 
+contains three sections with distinct parameters:
 
 ### `service`
 
@@ -149,7 +173,6 @@ The `serverless.yml` file is referencing both an `echo` directory (under `builda
 
 In the `serverless.yml` example above, the function name is `echo` and the subsequent lines contain the function attributes.
 
-
 | Parameter | Description |
 |-----------|-------------|
 | `handler` | The function's file name. In the example above, both the function name and the handler are the same. |
@@ -159,8 +182,7 @@ In the `serverless.yml` example above, the function name is `echo` and the subse
 | `environment` | Sets an environment variable for the specific function only. |
 
 After the `gitlab-ci.yml` template has been added and the `serverless.yml` file has been 
-created, each function must be defined as a single file in your repository. Committing a 
-function to your project will result in a
+created, pushing a commit to your project will result in a
 CI pipeline being executed which will deploy each function as a Knative service.
 Once the deploy stage has finished, additional details for the function will
 appear under **Operations > Serverless**.
@@ -182,14 +204,6 @@ The sample function can now be triggered from any HTTP client using a simple `PO
 
 ![function exection](img/function-execution.png)
 
-Currently, the Serverless page presents all functions available in all clusters registered for the project with Knative installed.
-
-Clicking on the function name will provide additional details such as the
-function's URL as well as runtime statistics such as the number of active pods
-available to service the request based on load.
-
-![serverless function details](img/serverless-details.png)
-
 ## Deploying Serverless applications
 
 > Introduced in GitLab 11.5.
@@ -227,12 +241,12 @@ deploy:
     - tm -n "$KUBE_NAMESPACE" --config "$KUBECONFIG" deploy service "$CI_PROJECT_NAME" --from-image "$CI_REGISTRY_IMAGE" --wait
 ```
 
-## Deploy the application with Knative
+### Deploy the application with Knative
 
 With all the pieces in place, the next time a CI pipeline runs, the Knative application will be deployed. Navigate to
 **CI/CD > Pipelines** and click the most recent pipeline.
 
-## Obtain the URL for the Knative deployment
+### Obtain the URL for the Knative deployment
 
 Use the CI/CD deployment job output to obtain the deployment URL. Once all the stages of the pipeline finish, click the **deploy** stage.