Commit bfd17bca authored by Grzegorz Bizon's avatar Grzegorz Bizon

Update GitLab Serverless documentation to use `gitlabktl`

parent da38bdc2
......@@ -91,10 +91,11 @@ Using functions is useful for dealing with independent
events without needing to maintain a complex unified infrastructure. This allows
you to focus on a single task that can be executed/scaled automatically and independently.
Currently the following [runtimes](https://gitlab.com/triggermesh/runtimes) are offered:
Currently the following [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes) are offered:
- ruby
- node.js
- kaniko
- Dockerfile
You can find and import all the files referenced in this doc in the **[functions example project](https://gitlab.com/knative-examples/functions)**.
......@@ -113,13 +114,17 @@ Follow these steps to deploy a function using the Node.js runtime to your Knativ
include:
template: Serverless.gitlab-ci.yml
functions:
functions:build:
extends: .serverless:build:functions
environment: production
functions:deploy:
extends: .serverless:deploy:functions
environment: production
```
This `.gitlab-ci.yml` creates a `functions` job that invokes some
predefined commands to deploy your functions to your cluster.
This `.gitlab-ci.yml` creates jobs that invokes some predefined commands to
build and deploy your functions to your cluster.
`Serverless.gitlab-ci.yml` is a template that allows customization.
You can either import it with `include` parameter and use `extends` to
......@@ -137,29 +142,40 @@ Follow these steps to deploy a function using the Node.js runtime to your Knativ
You can find the relevant files for this project in the [functions example project](https://gitlab.com/knative-examples/functions).
```yaml
service: my-functions
description: "Deploying functions from GitLab using Knative"
service: functions
description: "GitLab Serverless functions using Knative"
provider:
name: triggermesh
registry-secret: gitlab-registry
environment:
FOO: BAR
FOO: value
functions:
echo:
handler: echo
runtime: https://gitlab.com/triggermesh/runtimes/raw/master/nodejs.yaml
description: "echo function using node.js runtime"
buildargs:
- DIRECTORY=echo
echo-js:
handler: echo-js
source: ./echo-js
runtime: https://gitlab.com/gitlab-org/serverless/runtimes/nodejs
description: "node.js runtime function"
environment:
MY_FUNCTION: echo-js
echo-rb:
handler: MyEcho.my_function
source: ./echo-rb
runtime: https://gitlab.com/gitlab-org/serverless/runtimes/ruby
description: "Ruby runtime function"
environment:
MY_FUNCTION: echo-rb
echo-docker:
handler: echo-docker
source: ./echo-docker
description: "Dockerfile runtime function"
environment:
FUNCTION: echo
MY_FUNCTION: echo-docker
```
The `serverless.yml` file references 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:
Explanation of fields used above:
### `service`
......@@ -173,7 +189,6 @@ contains three sections with distinct parameters:
| Parameter | Description |
|-----------|-------------|
| `name` | Indicates which provider is used to execute the `serverless.yml` file. In this case, the TriggerMesh `tm` CLI. |
| `registry-secret` | Indicates which registry will be used to store docker images. The sample function is using the GitLab Registry (`gitlab-registry`). A different registry host may be specified using `registry` key in the `provider` object. If changing the default, update the permission and the secret value on the `gitlab-ci.yml` file |
| `environment` | Includes the environment variables to be passed as part of function execution for **all** functions in the file, where `FOO` is the variable name and `BAR` are he variable contents. You may replace this with you own variables. |
### `functions`
......@@ -182,10 +197,10 @@ In the `serverless.yml` example above, the function name is `echo` and the subse
| Parameter | Description |
|-----------|-------------|
| `handler` | The function's file name. In the example above, both the function name and the handler are the same. |
| `handler` | The function's name. |
| `source` | Directory with sources of a functions. |
| `runtime` | The runtime to be used to execute the function. |
| `description` | A short description of the function. |
| `buildargs` | Pointer to the function file in the repo. In the sample the function is located in the `echo` directory. |
| `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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment