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.
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.
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:
`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`.
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.
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:
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.
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.