Managing Your Serverless Functions With TriggerMesh and GitHub Actions

GitHub Actions is a new and very powerful feature. It can be used to create a release and deploy code through various environments depending on which branch the changes go. It can be used to perform a basic collection of tests on the creation of a pull request, or trigger any number of events in a more flexible fashion. What if there is a need to trigger something to occur that falls outside of a normal git hook?

For this simple example, a Serverless function will be placed in a GitHub repository. From there, a GitHub action will be used to build the function, and publish it in TriggerMesh. The ultimate goal is for a commit made to the master branch to trigger an update to the published function.

Register for TriggerMesh Early Adopter Program and Obtain TriggerMesh Configuration

If you haven’t signed up yet, then go to https://cloud.triggermesh.io/signup. Once that is completed, your email address can be used to access the TriggerMesh cloud.

The TriggerMesh dashboard will be the first thing that appears in the browser. Click on the cloud image to obtain the TriggerMesh config file. This will contain the configuration and credentials required to access your triggermesh account from anywhere, and will be required for the next step.

The Repository and Environment Setup

Create a new repository in GitHub. For this example, there will be a `serverless.yaml` file that will be used to create a manifest of the serverless functions being maintained, and then the sub directory for each of the functions. In this example, a single python script will be used.

The `serverless.yaml` file will look like:

service: tm-actions-test
description: "GitHub Actions Test with TriggerMesh"

provider:
  name: triggermesh

functions:
  actiontest:
    handler: actiontest
    description: "A sample test function that will just accept a request"
    runtime: https://raw.githubusercontent.com/triggermesh/openfaas-runtime/master/python2.7/openfaas-python2.7-runtime.yaml
    buildargs:
    - HANDLER=index.py
    - DIRECTORY=actiontest

`actiontest` is the name of the function as well as the directory that contains
the serverless function. The `runtime` defines a docker image that will act as
a container for the function. The `buildargs` will be passed to the runtime
engine, and specifies the directory of the service `actiontest`, and the python
script to invoke `index.py`.

Put this in the directory: `actiontest/index.py`.

import sys

def handle(req):
    print("Hello: " + req)

def get_stdin():
    buf = ""
    for line in sys.stdin:
        buf = buf + line
    return buf

if __name__ == "__main__":
    st = get_stdin()
    ret = handle(st)
    if ret != None:
        print(ret)

The python script itself is fairly simple in that it reads data passed in via `stdin`, and emits it with a “Hello”. Everything else is abstracted away.

With the serverless function and manifest in place, the last part prior to adding the action is to take the TriggerMesh config file from the previous step, and add it as a secret. Go to the repository settings, and click on the `Secrets` tab. For this example, it will be called `TM_CONFIG`. Paste the contents of the `config.json` file that was previously downloaded and save the new secret.

Adding the Action

If the project has been enabled to utilize Actions, then there should be an `Actions` tab accessible. Click on it, and the button `Set up a workflow yourself`.

The following code can be used to provide basis of an action that will use the TriggerMesh:

name: Deploy Service

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    container:
      image: docker://gcr.io/triggermesh/tm:latest
    steps:
    - uses: actions/checkout@master
    - name: Setup Configuration
      env:
        TM_CONFIG: ${{ secrets.TM_CONFIG }}
      run: |
        mkdir $HOME/.tm
        echo "${TM_CONFIG}" > $HOME/.tm/config.json
    - name: Use tm-cli to deploy
      run: |
        /usr/bin/tm deploy --wait

From this snippet, the reference to `docker://gcr.io/triggermesh/tm:latest` pulls in an image with the latest version of the CLI. The `Setup Configuration` migrates the contents of the `config.json` that was added as a secret in the previous step, and ensures it gets added in a known location. Lastly, `tm deploy –wait` is invoked to build the serverless functions in the TriggerMesh cluster, and deploy it. At the end of the run will be a URL to access the deployed services.

Conclusion for Managing Your Serverless Functions

Going from zero to having a serverless function managed in GitHub can be fairly simple to setup, and even simpler to maintain. To add or update a new service, a new directory with the serverless function handle, and an update of the `serverless.yaml` file to include the new service is all that is needed. The GitHub action takes care of the rest of ensure that the appropriate services
get added and updated.