Skip to content

Latest commit

 

History

History
37 lines (19 loc) · 2.91 KB

release.md

File metadata and controls

37 lines (19 loc) · 2.91 KB
Raw

Release Process

Our release process is automated by a couple of GitHub Actions (Update Plugins-dev and Release Plugins).

The process publishes two types of releases:

  • dev builds: the process is fully automated, and it is triggered when changes are merged into master branch
  • stable builds: the process is automated, but it needs to be manually triggered by tagging a plugin with a release version (see the section below)

Regardless of the type, if a plugin provides a ruleset, the ruleset is released, too, with the same version number. This may change in the future. Also, see Versioning a rulset guidelines before deciding the release version number.

Artifacts will be published at https://download.falco.org/?prefix=plugins/. For stable builds, OCI artifacts are published too. They can be consumed with falcoctl.

Tag format (stable build only)

Since the plugins repository is a monorepo, we introduced a special convention for tagging release versions, so that we can differentiate among plugins. Git tag MUST respect the following format:

name-version

Where name is the plugin name (must match a folder under ./plugins) and version is the plugin version to be released (must match the version string declared by the plugin).

Release a plugin (stable build only)

When we release, we do the following process:

  1. When changes are introduced to a plugin (i.e. a PR gets merged) and its version has been bumped, we choose the git tag based on the above convention
  2. A person with repository rights creates a new release from the GitHub UI
  3. Once the CI has done its job, the tag is live on Github, and the plugin package is published at download.falco.org

Publish OCI artifacts

After releasing one or more plugins in a row, we manually run the Update OCI Artifacts workflow in GitHub action. The CI job will check for the latest versions and build and publish the corresponding OCI artifacts.

Important note: This is a manual process to have room to roll back a plugin release. A step that allows manual double-checking is crucial until we have a proper e2e testing suite to ensure our releases do not break users' installations (users may have activated the automatic artifact updating feature provided by falcoctl).