Skip to content

Releases: cloudbase/garm

garm v0.2.0-beta1

13 Apr 11:26

Choose a tag to compare

GARM v0.2.0-beta1

This is the first beta release from the v0.2 branch, representing a major evolution of GARM. The headline features are GitHub Actions Runner Scale Sets, Gitea forge support, Agent Mode with remote shell access, and a brand new SPA Web UI.


New Features

Scale Sets

GARM now supports GitHub Actions Runner Scale Sets as a first-class alternative to webhook-driven pools. Scale sets use GitHub's native HTTP long-polling message queue API instead of webhooks, providing:

  • No webhooks required -- jobs are received via long-poll message sessions, eliminating the need for publicly-reachable webhook endpoints and the risk of lost webhook deliveries.
  • GitHub-managed scheduling -- GitHub controls which runner executes which job, improving scheduling efficiency within runner groups.
  • Full lifecycle management -- scale sets automatically create JIT (Just-In-Time) runners, provision instances through providers, and clean up after job completion.
  • Automatic scaling -- min idle runners and max runners limits are enforced with configurable bootstrap timeouts.
  • Runner group assignment -- scale sets can target specific GitHub runner groups at the organization and enterprise levels.
  • Label support -- scale sets support custom labels/tags for workflow runs-on targeting.
  • New CLI commands: garm-cli scaleset list|show|add|update|delete and garm-cli scaleset runner list.
  • New API endpoints: GET/POST/PUT/DELETE /scalesets, GET /scalesets/{id}/instances.
  • Full Web UI integration with create, update, and delete support.

Gitea Forge Support (Multi-Forge Architecture)

GARM is no longer GitHub-only. A major refactor introduces a multi-forge architecture with Gitea as the first additional forge:

  • Gitea endpoints -- create and manage Gitea server endpoints with api_base_url, base_url, CA cert bundles, and custom tools metadata URLs.
  • Gitea credentials -- PAT-based authentication for Gitea instances.
  • Repository and organization support -- manage Gitea repos and orgs the same way as GitHub entities.
  • Webhook management -- automatic webhook installation/uninstallation for Gitea repos and orgs.
  • Gitea runner tools -- automatic fetching of act_runner releases from Gitea's public repository, with support for custom tools metadata URLs and internal tools hosting.
  • Forge type namespacing -- credentials and endpoints are namespaced by forge type, preventing collisions.
  • --forge-type flag -- optional on repo create and org create (auto-detected from credentials when omitted).
  • Docker compose examples -- ready-to-use examples for setting up GARM with Gitea.

Agent Mode

A new deployment model where GARM installs and manages a persistent garm-agent on runner instances:

  • Per-entity toggle -- enable agent mode on individual repos, orgs, or enterprises via --agent-mode flag.
  • Object store -- new built-in file storage system for managing garm-agent binaries, with upload/download/delete/list/search via API, CLI, and Web UI.
  • Automatic tool sync -- GARM periodically fetches the latest garm-agent releases from an upstream GitHub repository and stores them locally. Manual uploads take priority over auto-synced tools.
  • WebSocket agent connectivity -- agents connect back to the controller via persistent WebSocket, enabling bidirectional communication.
  • Remote shell access -- administrators can open interactive shell sessions on running agents directly from the Web UI (using xterm.js) or API, with per-pool/scale-set enable/disable control.
  • Agent heartbeats -- live agent health monitoring with heartbeat staleness detection in the UI.
  • Metadata URL -- new metadata_url controller setting. AgentURL is auto-derived from MetadataURL or CallbackURL if not explicitly set.
  • New API endpoints for tool management: GET/POST/DELETE /tools/garm-agent, GET /tools/garm-agent/{id}/download, POST /tools/garm-agent/sync.
  • New CLI commands: garm-cli tools list|upload|delete|force-sync.

Web UI (SPA)

A brand new Single Page Application built with SvelteKit, TypeScript, and Tailwind CSS, embedded directly into the GARM binary:

  • Dashboard -- overview of all entities, pools, scale sets, and system status with a setup wizard for first-time configuration.
  • Entity management -- full CRUD for repositories, organizations, and enterprises with pool and scale set management inline.
  • Pool and scale set management -- create, update, delete pools and scale sets with tag editing, runner group assignment, and template selection.
  • Credentials management -- create, update, delete credentials with a dedicated details page showing associated entities.
  • Endpoint management -- create, update, delete GitHub and Gitea endpoints with CA cert upload.
  • Runner/Instance management -- list all runners with status badges, detail pages with live event logs, and delete actions.
  • Runner install templates -- manage custom runner installation templates.
  • Object storage browser -- upload, download, search, and manage files in the object store.
  • Real-time updates -- WebSocket integration for live entity and instance status updates with connection status indicator.
  • Shell terminal -- integrated xterm.js terminal for agent-mode runners with multi-tab support, maximize/minimize, and drag-to-resize.
  • Webhook management -- install/uninstall webhooks from entity detail pages.
  • Dark mode -- full dark/light theme support.
  • Responsive design -- mobile-first layout with DataTable components that switch between card (mobile) and table (desktop) views.
  • Embeddable -- built assets are compiled into the Go binary via go:embed. No external file serving needed.
  • Reverse proxy support -- can be served behind nginx or similar, with documented config for WebSocket upgrades.

Enable the Web UI in your config:

[apiserver.webui]
  enable=true

Then navigate to http://<your-garm-host>:<port>/ui/.

Metrics & Observability

  • Job metrics -- new Prometheus metrics for workflow jobs including owner, workflow name, scale set job ID, and job URL.
  • Rate limit metrics -- GitHub/Gitea API rate limit consumption is now exposed as Prometheus metrics with per-credentials tracking.
  • GitHub operation metrics -- operation counts and failure counts by operation type and entity scope.

Runner Install Templates

  • Template management -- create, list, get, update, and delete custom runner installation templates via API, CLI (garm-cli template list|show|add|update|delete|restore), and Web UI.
  • Template restore -- restore built-in default templates if customized templates are broken.
  • Per-pool/scale-set template assignment -- pools and scale sets can reference a specific template by ID.
  • Forge-aware templates -- separate templates for GitHub and Gitea, for both Linux and Windows.
  • No more jq requirement -- runner install scripts no longer require jq to be installed at runtime.

Generation Tracking and Runner Rotation

  • Generation tracking -- pools and scale sets now track a configuration generation counter. When configuration changes (image, flavor, extra specs, etc.), the generation increments, allowing identification of instances running with outdated configuration.
  • Runner rotation -- new garm-cli pool runner rotate and garm-cli scaleset runner rotate commands allow rotating runners, with --outdated filtering to target only instances from a previous generation, and --dry-run mode to preview changes.

CA Certificate Bundle for Controller

  • CA bundle in controller settings -- a configurable CA certificate bundle can be set at the controller level. It is automatically injected into runner userdata, allowing runners to trust custom/internal CAs when communicating with the GARM controller. Windows is also supported.

Improvements

CLI

  • garm-cli top -- new interactive terminal dashboard for monitoring live GARM metrics. Displays a multi-panel TUI with summaries of entities, pools, scale sets, instances, and jobs. Refreshes in real-time via WebSocket. Navigate panels with Tab and scroll with arrow keys.
  • Friendly names everywhere -- most commands now accept entity names in addition to UUIDs.
  • --endpoint flag -- added to all relevant commands for filtering by endpoint.
  • --filter option -- rudimentary filter support when listing entities.
  • Improved garm-cli debug-log -- streams GARM server logs in real-time via WebSocket with rich formatting:
    • Color-coded output -- log levels are color-coded (red for ERROR, yellow for WARN, blue for INFO, magenta for DEBUG) with auto-detection of terminal color support. Override with --enable-color, NO_COLOR=1, or FORCE_COLOR=1.
    • Log level filtering (--log-level) -- filter by minimum level (DEBUG, INFO, WARN, ERROR).
    • Attribute filtering (--filter key=value) -- filter log entries by attribute values or message content (msg=text). Can be specified multiple times.
    • Filter mode (--filter-mode any|all) -- choose between OR (any filter matches) or AND (all filters must match) logic.
    • Highlighting (--highlight key) -- highlight specific attributes or message content in the output.
  • Runner referencing by ID -- runners can now be referenced by their numeric ID in addition to name.

garm-cli top

tmp1rrwhpjf-ascii

garm-cli debug-log

tmp9ghztnqg-ascii

Performance & Caching

  • **Entity loading in paralle...
Read more

garm v0.1.8

20 Mar 12:48

Choose a tag to compare

Welcome to GARM v0.1.8

This is a bugfix release.

What's Changed

Full Changelog: v0.1.6...v0.1.8

garm v0.1.7

23 Jan 13:14

Choose a tag to compare

Welcome to GARM v0.1.7!

This is a bugfix release. No new features were added.

What's Changed

Full Changelog: v0.1.6...v0.1.7

garm v0.1.6

20 Jul 01:20
50d2546

Choose a tag to compare

Welcome to GARM v0.1.6!

Starting with this release, GARM will now have a release/v0.1 and a release/v0.2 (which will receive updates from main) channel. The v0.1.X releases will contain no new major features, just bug fixes. The goal is to offer a stable release that will work with any existing integrations like the k8s operator, and still allow to break compatibility and add new features.

The main branch will now diverge from release/v0.1 and checkpoints from main will be merged into release/v0.2.

That being said, this release has a number of stability fixes and bug fixes that should help especially for environments that are under heavy load.

New Linode provider

Thanks to @tormath1 we can now create runners on Linode. This new provider is included in the v0.1.6 container image.

What's Changed

Full Changelog: v0.1.5...v0.1.6

garm v0.1.5

08 Aug 13:41
237afdb

Choose a tag to compare

Welcome to GARM v0.1.5!

Before we dive into the highlights, as always a few notes.

Database upgrade ⚠️

This version will execute a database migration. While we try not to break anything when making database migrations, it's always a good idea to create a backup of your DB as well as any configuration files. If anything goes wrong, you can revert the changes. Database downgrades are not supported. If you need to go back to a previous version, please also restore the DB from backup.

To safely create a backup of you DB, you can use the sqlite3 CLI:

# Change the path to your DB to the one configured in your config.toml
sqlite3 /etc/garm/garm.db
.backup /path/to/backup/location/garm-backup.db

Breaking changes ⚠️

This version has moved a number of options from the config file, to the database. During the upgrade process from v0.1.4 to v0.1.5 please do not make any changes to your current config. GARM will read the config and migrate any of the settings present there, to the DB, automatically. After you start GARM with the new version and the migration has finished (it should be just a matter of seconds), you can then edit your config and remove the relevant fields.

Things that have been moved from the config to the database:

  • The metadata_url, callback_url and webhook_url settings have now been moved to the database in the controller table. These settings can now be updated using the garm-cli command line tool.
  • Github credentials - credentials are now created via the garm-cli command line tool. Details bellow.

Note

If you receive an error regarding missing URLs, you must update your controller settings using garm-cli controller update. Make sure all your URLs are up to date, including the webhooks URL.

Highlights

This version is packed with features and changes. Although GARM can handle a large amount of runners with ease, we are working towards enabling it to eventually scale out. As a result, we've started moving some of the settings that were in the config file, to the database. The goal is to eventually have a single source of truth for those settings and enable GARM to react to any changes immediately without the need to reload the app. This is just one motivation behind the changes in this release, but as you'll see, there are many other changes that enable you to do more with GARM.

GitHub endpoints

With the migration of credentials to the database, GARM now has the notion of "github endpoints". A github endpoint represents a deployment of GHES or GitHub itself. It is a way to tell GARM to which API endpoints it needs to connect in order to use the supplied credentials or to execute operations against a particular entity (repo, org or enterprise).

All github credentials and all entities are now bound to a github endpoint. This ensures consistency and correctness when dealing with these types of resources.

See the github endpoint section of the documentation.

Github App Support

We now have the ability to configure GARM to use GitHub Apps to access the github API. This gives us a much higher rate limit for API calls (15.000/hour compared to 5000/hour as is the case of PATs).

Check out the github credentials documentation section for more info on how to configure app credentials, as well as the required credentials for GitHub Apps.

All sensitive info is encrypted at rest and is never returned by the API.

Runner default labels

Starting with version v2.305.0 of the GitHub actions runner, the default lables ($ARCH, $OS and self-hosted) are no longer added if the --no-default-labels flag is used. GARM now takes advantage of this feature to create runners without default labels. The default labels can still be added explicitly if you require them.

Pool balancing strategies

You can now specify two modes of balancing for jobs that get handled by a configured entity. The balancing mode can be set on the entity itself, and this will influence how the pool manager for that entity will behave. The two modes of operation are:

  • roundrobin - During the consolidation loop, if we have multiple queued jobs, the roundrobin strategy will balance each job to a different matching pool. This is useful if you want to spread the workload evenly across multiple clouds or regions. This is the default.
  • pack - The pack strategy will try to fill up the first pool before moving on to the next, This is useful if you have cheap runners you want to use first before moving on to pools of more expensive runners.

To set the balancing stratedy for a repo, org or enterprise you can use the following command:

garm-cli repo update --pool-balancer-type pack <repo_id>

Additionally, pools now have a priority field. This priority field is used when sorting pools that match jobs which need to be handled. You can set the priority when you create the pool or you can update it later. The higher the number, the more likely the pool is to be at the beginning of the list.

A new events websocket endpoint

We now have a new websocket endpoint that can be used by projects which integrate with GARM. This websocket endpoint streams database events as they happen in GARM itself, allowing applications to not need to poll for updates.

Here is a demo of an earlier implementation, in action:

asciicast

For details regarding the current implementation and how to use it, check out the documentation.

There are many other fixes and features added to this release, a lot of which are internal to GARM but they do have a positive impact on stability and reliability. I invite you to check out the full list of changes, bellow.

Thanks to everyone that has contributed to this release, be it via pull requests, raising issues or helping us debug weird behavior!

What's Changed

Read more

garm v0.1.4

12 Feb 20:07

Choose a tag to compare

Welcome to GARM version v0.1.4!

Documentation relevant to this version is available at: https://github.com/cloudbase/garm/tree/v0.1.4. The main branch contains code that is still under development, and the documentation is relevant to that code. When deploying stable versions, please view the docs available under the relevant tag.

Before we dive into the highlights, there are a couple of things we need to mention.

Breaking change warning ⚠️

This version removes the LXD internal provider in favor of two new external providers:

This was done mainly due to the licensing change of LXD. If you're using LXD and are upgrading from previous versions, you must download the LXD external provider and configure it.

Another breaking (sort of) change is in the garm-cli. The --force flag in the runner remove command, is no longer mandatory when removing a runner. Moreover, the --force flag now ignores provider errors. In previous versions, if a provider erred when removing a runner, GARM would keep trying until it succeeded. The problem was that if a provider was misconfigured, we would be stuck with a runner in error state until re manually removed it from the database. The --force flag allows us to remove a runner from GARM even if the provider returns an error.

Database upgrade ⚠️

This version will execute a database migration. While we try not to break anything when making database migrations, it's always a good idea to create a backup of your DB as well as any configuration files. If anything goes wrong, you can revert the changes.

To safely create a backup of you DB, you can use the sqlite3 CLI:

# Change the path to your DB to the one configured in your config.toml
sqlite3 /etc/garm/garm.db
.backup /path/to/backup/location/garm-backup.db

Highlights

This release is packed with optimizations, changes and a couple of nice features.

JIT runners

The main highlight of this release is the ability to use just-in-time self-hosted runners. To accommodate this change, GARM now has more robust metadata endpoints that can serve the needed JIT files. This will most likely be expanded in the future to include setup scripts for clouds where we have userdata size constraints.

JIT runners allows us to avoid sending a runner registration token over the wire. Registration tokens can be used to register multiple runners and have a validity of one hour. A bad actor may intercept this token and use it to register their own runners. With JIT runners, only one runner may use the credentials at any given point in time. The credentials are fetched from GARM by the runner when it spins up.

This feature can be disabled in the provider config by specifying:

[[provider]]
disable_jit_config = true

easily access controller info

We now have the ability to gain more insight into how GARM is configured. We've added a new command which can show us some info about the controller:

ubuntu@garm:~$ garm-cli controller-info show
+------------------------+----------------------------------------------------------------------------+
| FIELD                  | VALUE                                                                      |
+------------------------+----------------------------------------------------------------------------+
| Controller ID          | a4dd5f41-8e1e-42a7-af53-c0ba5ff6b0b3                                       |
| Hostname               | garm                                                                       |
| Metadata URL           | https://garm.example.com/api/v1/metadata                                   |
| Callback URL           | https://garm.example.com/api/v1/callbacks                                  |
| Webhook Base URL       | https://garm.example.com/webhooks                                          |
| Controller Webhook URL | https://garm.example.com/webhooks/a4dd5f41-8e1e-42a7-af53-c0ba5ff6b0b3     |
+------------------------+----------------------------------------------------------------------------+

Easy webhook installation

Installing webhooks for entities (repos, orgs, enterprises) can be a chore. In this version, we've added the ability to let GARM install the needed webhook, with the correct settings by running a simple command. To make use of this feature, the PAT you're using must have access to admin:org_hook:

ubuntu@garm:~$ garm-cli org add \
    --credentials org_token \
    --name exampleOrg \
    --install-webhook  \
    --random-webhook-secret
+----------------------+--------------------------------------+
| FIELD                | VALUE                                |
+----------------------+--------------------------------------+
| ID                   | b90911e1-8727-4bb7-a1eb-96855d73a27b |
| Name                 | exampleOrg                           |
| Credentials          | org_token                            |
| Pool manager running | true                                 |
+----------------------+--------------------------------------+

This command will add the org exampleOrg to your GARM controller and install a webhook for it with a random webhook secret. You can also install a webhook for an existing organization or repository:

ubuntu@garm:~$ garm-cli repo webhook install b90911e1-8727-4bb7-a1eb-96855d73a27b
+--------------+----------------------------------------------------------------------------+
| FIELD        | VALUE                                                                      |
+--------------+----------------------------------------------------------------------------+
| ID           | 449734752                                                                  |
| URL          | https://garm.example.com/webhooks/a4dd5f41-8e1e-42a7-af53-c0ba5ff6b0b3     |
| Events       | [workflow_job]                                                             |
| Active       | true                                                                       |
| Insecure SSL | false                                                                      |
+--------------+----------------------------------------------------------------------------+

To view the status of a webhook:

ubuntu@garm:~$ garm-cli repo webhook show b90911e1-8727-4bb7-a1eb-96855d73a27b
+--------------+----------------------------------------------------------------------------+
| FIELD        | VALUE                                                                      |
+--------------+----------------------------------------------------------------------------+
| ID           | 449734752                                                                  |
| URL          | https://garm.example.com/webhooks/a4dd5f41-8e1e-42a7-af53-c0ba5ff6b0b3     |
| Events       | [workflow_job]                                                             |
| Active       | true                                                                       |
| Insecure SSL | false                                                                      |
+--------------+----------------------------------------------------------------------------+

You can also uninstall a webhook:

ubuntu@garm:~$ garm-cli repo webhook uninstall b90911e1-8727-4bb7-a1eb-96855d73a27b

Webhooks installed by the above commands are always namespaced to the controller ID you get when you run garm-cli controller-info show. This way, when we remove a webhook, we don't accidentally remove someone else's hook. You can also manually install we webhook just like before. You don't need to namespace it to the controller ID. GARM will see the webhook and let you know if the hook is already installed.

Removing a repo or org will also clean up the webhook if it was namespaced to our controller. You can opt to keep the hook by passing the --keep-webhook flag.

Webhook installation is not available for enterprises.

Structured logging

GARM has now switched to the slog standard package for structured logging. As part of this change, we now have a dedicated [logging] config section where you can set the log level, log format, enable the log streamer, etc. Check out the sample config for more info.

Other updates

There are a lot of bug fixes and stability updates that should make this version behave better in relation to the GitHub API.

What's Changed

Read more

garm v0.1.4-rc1

18 Dec 19:25

Choose a tag to compare

garm v0.1.4-rc1 Pre-release
Pre-release

Welcome to GARM version v0.1.4-rc1!

This is a pre-release of GARM and it is packed with changes.

Before we dive into the highlights, there are a couple of things we need to mention.

Breaking change warning ⚠️

This version removes the LXD internal provider in favour of two new external providers:

This was done mainly due to the licensing change of LXD. If you're using LXD and are upgrading from previous versions, you must download the LXD external provider and configure it.

Database upgrade ⚠️

This version will execute a database migration. While we try not to break anything when making database migrations, it's always a good idea to create a backup of your DB as well as any configuration files. If anything goes wrong, you can revert the changes.

To safely create a backup of you DB, you can use the sqlite3 CLI:

# Change the path to your DB to the one configured in your config.toml
sqlite3 /etc/garm/garm.db
.backup /path/to/backup/location/garm-backup.db

Highlights

This release is packed with optimizations, changes and a couple of nice features.

JIT runners

The main highlight of this release is the ability to use just-in-time self-hosted runners. To accommodate this change, GARM now has more robust metadata endpoints that can serve the needed JIT files. This will most likely be expanded in the future to include setup scripts for clouds where we have userdata size constraints.

JIT runners allows us to avoid sending a runner registration token over the wire. Registration tokens can be used to register multiple runners and have a validity of one hour. A bad actor may intercept this token and use it to register their own runners. With JIT runners, only one runner may use the credentials at any given point in time. The credentials are fetched from GARM by the runner when it spins up.

This feature can be disabled in the provider config by specifying:

[[provider]]
disable_jit_config = true

easily access controller info

We now have the ability to gain more insight into how GARM is configured. We've added a new command which can show us some info about the controller:

ubuntu@garm:~$ garm-cli controller-info show
+------------------------+----------------------------------------------------------------------------+
| FIELD                  | VALUE                                                                      |
+------------------------+----------------------------------------------------------------------------+
| Controller ID          | a4dd5f41-8e1e-42a7-af53-c0ba5ff6b0b3                                       |
| Hostname               | garm                                                                       |
| Metadata URL           | https://garm.example.com/api/v1/metadata                                   |
| Callback URL           | https://garm.example.com/api/v1/callbacks                                  |
| Webhook Base URL       | https://garm.example.com/webhooks                                          |
| Controller Webhook URL | https://garm.example.com/webhooks/a4dd5f41-8e1e-42a7-af53-c0ba5ff6b0b3     |
+------------------------+----------------------------------------------------------------------------+

Easy webhook installation

Installing webhooks for entities (repos, orgs, enterprises) can be a chore. In this version, we've added the ability to let GARM install the needed webhook, with the correct settings by running a simple command. To make use of this feature, the PAT you're using must have access to admin:org_hook:

ubuntu@garm:~$ garm-cli org add \
    --credentials org_token \
    --name exampleOrg \
    --install-webhook  \
    --random-webhook-secret
+----------------------+--------------------------------------+
| FIELD                | VALUE                                |
+----------------------+--------------------------------------+
| ID                   | b90911e1-8727-4bb7-a1eb-96855d73a27b |
| Name                 | exampleOrg                           |
| Credentials          | org_token                            |
| Pool manager running | true                                 |
+----------------------+--------------------------------------+

This command will add the org exampleOrg to your GARM controller and install a webhook for it with a random webhook secret. You can also install a webhook for an existing organization or repository:

ubuntu@garm:~$ garm-cli repo webhook install b90911e1-8727-4bb7-a1eb-96855d73a27b
+--------------+----------------------------------------------------------------------------+
| FIELD        | VALUE                                                                      |
+--------------+----------------------------------------------------------------------------+
| ID           | 449734752                                                                  |
| URL          | https://garm.example.com/webhooks/a4dd5f41-8e1e-42a7-af53-c0ba5ff6b0b3     |
| Events       | [workflow_job]                                                             |
| Active       | true                                                                       |
| Insecure SSL | false                                                                      |
+--------------+----------------------------------------------------------------------------+

To view the status of a webhook:

ubuntu@garm:~$ garm-cli repo webhook show b90911e1-8727-4bb7-a1eb-96855d73a27b
+--------------+----------------------------------------------------------------------------+
| FIELD        | VALUE                                                                      |
+--------------+----------------------------------------------------------------------------+
| ID           | 449734752                                                                  |
| URL          | https://garm.example.com/webhooks/a4dd5f41-8e1e-42a7-af53-c0ba5ff6b0b3     |
| Events       | [workflow_job]                                                             |
| Active       | true                                                                       |
| Insecure SSL | false                                                                      |
+--------------+----------------------------------------------------------------------------+

You can also uninstall a webhook:

ubuntu@garm:~$ garm-cli repo webhook uninstall b90911e1-8727-4bb7-a1eb-96855d73a27b

Webhooks installed by the above commands are always namespaced to the controller ID you get when you run garm-cli controller-info show. This way, when we remove a webhook, we don't accidentally remove someone else's hook. You can also manually install we webhook just like before. You don't need to namespace it to the controller ID. GARM will see the webhook and let you know if the hook is already installed.

Removing a repo or org will also clean up the webhook if it was namespaced to our controller. You can opt to keep the hook by passing the --keep-webhook flag.

Webhook installation is not available for enterprises.

Other updates

There are a lot of bug fixes and stability updates that should make this version behave better in relation to the GitHub API. I'm pretty sure I'm forgetting something, but you can consult the list bellow for a full list of changes.

In any case, take it for a spin! If you run into any issue, feel free to open a new issue.

What's Changed

Read more

garm v0.1.3

25 Jul 20:05
d2fb5e3

Choose a tag to compare

Welcome to GARM version v0.1.3!

This release brings a number of really nice improvements.

Highlights

Thanks to @mihaelabalutoiu, we now have proper OpenAPI annotations, as well as a full client generated from them. The GARM CLI has switched to this new client, which is located in the root of the project. If you plan to integrate with GARM in any way, I encourage you to use this client instead of the old, hand-written one we previously had.

Another interesting change in this release is the fact that we split some functionality from GARM itself, into an external package. This new package will hold functionality that is common to GARM itself and external providers.

As part of this migration we also added the ability to:

  • Completely override the runner installation script template. This can be done with any provider that leverages the new external package and calls the helper functions that generate the install script. This includes the current LXD, OpenStack and Azure providers.
  • Send additional template context (if overriding the install template)
  • For Linux only (for now):
    • Add pre-install scripts. These scripts are executed in alphabetical order before the runner install script is run.

This can all be done via extra-specs.

Upgrade notes

This update does not come with database schema changes, however, we do recommend you update any external providers to their latest versions if you update GARM.

What's Changed

Full Changelog: v0.1.2...v0.1.3

garm v0.1.2

06 Jul 06:41
a0a5611

Choose a tag to compare

Welcome to garm version v0.1.2!

This release brings a a lot of performance improvements and bug fixes.

Highlights

The most notable change in this release is in the way garm reacts to jobs sent by GitHub. Previously, garm reacted to new web hooks, but never recorded them in any way. When a queued hook came in, garm would attempt to create a new runner for it. The outcome of that action would depend on a few factors like if we had room for a new runner (max-runners), or if we had a pool that matched the requested tags.

One other shortcoming of the old approach was the fact that if we had multiple hierarchy levels configured (repo, org, enterprise), they would all receive the web hook with the queued job and would each create one runner for the same job. This had the potential to spin up resources for no reason.

This release introduces a new job tracking feature. From now on, garm will record all jobs that GitHub sends and the entity that received them (repo, org, enterprise). It will then attempt to periodically (roughly every 5 seconds) consume the jobs found in queued state and spin up runners for them. If we have multiple hierarchy levels configured, they will contend to spin up a runner for a job, but in the end only one of them will spin up a runner. This reduces the number of runners that get spun up for the same job. Job tracking also means that if a pool reaches max-runners we no longer lose jobs. We will eventually spin up a runner if the job is still in queued state. Which also means that it should be safe to use pools with min-idle-runners set to zero.

Other highlights

  • WAL is now enabled for the DB store. This was an oversight that caused load on large scale deployments.
  • Aditional indexes have been created for further speedups
  • Pool manager loops have been refactored. Each operation now runs in their own loop.
  • If multiple pools match a certain label, garm will now attempt to round-robin runners in matching pools

Upgrade notes

This release brings a number of changes to the database. Please back up your sqlite database before updating. The procedure is simple:

systemctl stop garm
cp /etc/garm/garm.db   /etc/garm/garm.db.backup
# update garm then start
systemctl start garm

What's Changed

New Contributors

Full Changelog: v0.1.1...v0.1.2

garm v0.1.1

16 Jun 14:47
481ce34

Choose a tag to compare

Welcome to garm version v0.1.1!

This release adds some resiliency fixes to garm.

Highlights

  • Instances that fail to set up their GitHub agent and transition to failed are now reaped.
  • The cloud-init userdata now retries setting up the github agent for up to 5 times before giving up
  • You can now specify extra_packages extra specs with the LXD provider, which allows you to install additional packages on runner nodes. (#103)

What's Changed

New Contributors

Full Changelog: v0.1.0...v0.1.1