GARM Helm Chart

This Helm chart deploys GARM (GitHub/Gitea Actions Runner Manager) on a Kubernetes cluster.

Note

This is an unofficial Helm chart and is not affiliated with the GARM project. Please do not open issues regarding this chart in the official GARM repository.

Chart Status & Expectations

• This chart was initially created for a specific use case (Gitea with a GCP provider). For other scenarios, it is provided on a best-effort basis. Pull requests are highly encouraged and welcome.
• The chart relies on unreleased GARM features (e.g., WebUI, Gitea forge support). Right now it uses a pinned nightly image hash that has been tested. Using other image versions or tags may result in partial or complete failure.

Architecture

This chart uses an operator-like pattern, launching two pods:

• GARM Server (Deployment): The main GARM application that runs continuously.
• Operator (Job): A one-time job that runs during helm install or helm upgrade to apply declarative configurations for forges, providers, and runner pools from your values.yaml.

Installation

1. Create a copy of values.yaml (e.g., my-values.yaml) and customize it for your environment.
2. Install the chart:

   helm install -f my-values.yaml my-garm oci://ghcr.io/igrikus/garm

Configuration

All configuration is managed through the values.yaml file, which serves as the single source of truth for your GARM deployment. Please refer to the comments within values.yaml for detailed information on all available options.

Pool Management

This chart provides a convenient way to manage GARM pools directly from your values.yaml file.

Important Notes:

• Gitea Exclusive: Currently, this declarative pool management feature is only implemented for Gitea forges.
• Pool Recreation: Pools are recreated on every helm upgrade to ensure they are always synchronized with the state defined in values.yaml. Any manual changes made to the pools via the GARM UI or API will be lost on chart upgrade

Contributing

Contributions are highly welcome! This project uses semantic-release to automate the release process, so it's important that all commit messages adhere to the Conventional Commits specification.

When you create a pull request, please make sure your commit messages are structured as follows:

<type>([optional scope]): <description>

[optional body]

Common commit types:

• fix: A bug fix. (Triggers a patch version release)
• feat: A new feature. (Triggers a minor version release)
• docs: Documentation only changes. (No release)
• refactor: A code change that neither fixes a bug nor adds a feature. (No release)
• test: Adding missing tests or correcting existing tests. (No release)
• chore: Changes to the build process or auxiliary tools and libraries such as documentation generation. (No release)

To indicate a breaking change (which triggers a major version release), add a ! after the type (e.g., feat!:) or include BREAKING CHANGE: in the commit message footer.

Examples:

No release

chore: change build process

patch release

fix: added icon

minor release

feat(server): Add option to configure liveness probe

major release

feat!: breaking change for pool creation logic

Following this convention is crucial as it directly controls the versioning and release notes for the chart.