This section describes how we can use GitHub Actions to automate as many tasks as possible.
The scaffolded project already includes all the GitHub actions you need.
These Actions can be found in the
rename it to
github/workflows.ci/yml to enable them.
The same principles can be adapted to use a different CI system.
Automation of the unit tests and of the end-to-end tests is working out of the
box thanks to the
e2e-tests jobs defined in
The scaffolded project contains a
release job in
This job performs the following steps:
- Checkout code
- Build the WebAssembly policy
- Push the policy to an OCI registry
- Eventually create a new GitHub Release
To enable the job you need to rename it to
ci.yml and change the value of the
OCI_TARGET to match your preferences.
The job will act differently based on the commit that triggered its execution.
Regular commits will lead to the creation of an OCI artifact called
No GitHub Release will be created for these commits.
On the other hand, creating a tag that matches the
v* pattern, will lead
- Creation of an OCI artifact called
- Creation of a GitHub Release named
Release <full tag name>. The release will include the following assets: the source code of the policy and the WebAssembly binary.
A concrete example
Let's assume we have a policy named
safe-labels and we want to publish
The contents of the
jobs.push-to-oci-registry.env section of
look like this:
Pushing a tag named
v0.1.0 will lead to the creation and publishing of the
OCI artifact called
A GitHub Release named
Release v0.1.0 will be created. The release will
include the following assets:
- Source code compressed as
- A file named
policy.wasmthat is the actual WebAssembly policy