GitHub Actions Runner Manager
Find a file
Gabriel Adrian Samfira affb56f9a0 Remove the LXD internal provider
Canonical have relicensed the LXD project to AGPLv3. This means that we can
no longer update the go LXD client without re-licensing GARM as AGPLv3. This
is not desirable or possible.

The existing code seems to be Apache 2.0 and all code that has already been
contributed seems to stay as Apache 2.0, but new contributions from Canonical
employees will be AGPLv3.

We cannot risc including AGPLv3 code now or in the future, so we will separate
the LXD provider into its own project which can be AGPLv3. GARM will simply
execute the external provider.

If the client code of LXD will ever be split from the main project and re-licensed
as Apache 2.0 or a compatible license, we will reconsider adding it back as a
native provider. Although in the long run, I believe external providers will
be the only option as they are easier to write, easier to maintain and safer to
ship (a bug in the provider does not crash GARM itself).

Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
2023-12-18 12:16:48 +00:00
.github/workflows Refactor integration E2E tests 2023-08-24 15:22:46 +03:00
apiserver Add force delete runner 2023-10-12 06:15:36 +00:00
auth Add temporary redirect to go-github fork 2023-09-24 13:49:04 +00:00
client Add force delete runner 2023-10-12 06:15:36 +00:00
cmd Add force delete runner 2023-10-12 06:15:36 +00:00
config Remove the LXD internal provider 2023-12-18 12:16:48 +00:00
contrib Rotate log file on SIGHUP 2023-06-27 20:04:20 +03:00
database Add force delete runner 2023-10-12 06:15:36 +00:00
doc feat: add new metrics 2023-10-06 10:21:56 +02:00
internal/testing Rename module 2023-03-12 16:01:49 +02:00
metrics feat: add new metrics 2023-10-06 10:21:56 +02:00
params Prevent abusing the GH API 2023-12-15 22:41:50 +00:00
runner Remove the LXD internal provider 2023-12-18 12:16:48 +00:00
scripts Enable Windows builds 2023-08-18 14:46:00 +00:00
test/integration Remove the LXD internal provider 2023-12-18 12:16:48 +00:00
testdata Update sample config 2023-12-11 14:05:10 +00:00
util Replace deprecated function call 2023-09-24 08:04:00 +00:00
vendor Remove the LXD internal provider 2023-12-18 12:16:48 +00:00
websocket Fixed a bunch of linting issues 2023-01-20 22:21:22 +02:00
.gitignore Refactor integration E2E tests 2023-08-24 15:22:46 +03:00
Dockerfile Enable Windows builds 2023-08-18 14:46:00 +00:00
Dockerfile.build-static Enable Windows builds 2023-08-18 14:46:00 +00:00
go.mod Remove the LXD internal provider 2023-12-18 12:16:48 +00:00
go.sum Remove the LXD internal provider 2023-12-18 12:16:48 +00:00
LICENSE Initial commit 2022-04-13 19:45:01 +03:00
Makefile Enable Windows builds 2023-08-18 14:46:00 +00:00
README.md Merge pull request #191 from gabriel-samfira/update-readme 2023-12-11 17:53:32 +02:00

GitHub Actions Runner Manager (GARM)

Go Tests

Welcome to GARM!

GARM enables you to create and automatically maintain pools of self-hosted GitHub runners, with auto-scaling that can be used inside your github workflow runs.

The goal of GARM is to be simple to set up, simple to configure and simple to use. It is a single binary that can run on any GNU/Linux machine without any other requirements other than the providers it creates the runners in. It is intended to be easy to deploy in any environment and can create runners in any system you can write a provider for. There is no complicated setup process and no extremely complex concepts to understand. Once set up, it's meant to stay out of your way.

GARM supports creating pools on either GitHub itself or on your own deployment of GitHub Enterprise Server. For instructions on how to use GARM with GHE, see the credentials section of the documentation.

Through the use of providers, GARM can create runners in a variety of environments using the same GARM instance. Want to create pools of runners in your OpenStack cloud, your Azure cloud and your Kubernetes cluster? No problem! Just install the appropriate providers, configure them in GARM and you're good to go. Create zero-runner pools for instances with high costs (large VMs, GPU enabled instances, etc) and have them spin up on demand, or create large pools of k8s backed runners that can be used for your CI/CD pipelines at a moment's notice. You can mix them up and create pools in any combination of providers or resource allocations you want.

Join us on slack

Whether you're running into issues or just want to drop by and say "hi", feel free to join us on slack.

slack

Installing

On virtual or physical machines

Check out the quickstart document for instructions on how to install GARM. If you'd like to build from source, check out the building from source document.

On Kubernetes

Thanks to the efforts of the amazing folks at @mercedes-benz, GARM can now be integrated into k8s via their operator. Check out the GARM operator for more details.

Supported providers

GARM has a built-in LXD provider that you can use out of the box to spin up runners on any machine that runs either a stand-alone LXD instance, or an LXD cluster. The quick start guide mentioned above will get you up and running with the LXD provider.

GARM also supports external providers for a variety of other targets.

Installing external providers

External providers are binaries that GARM calls into to create runners in a particular IaaS. There are currently two external providers available:

Follow the instructions in the README of each provider to install them.

Configuration

The GARM configuration is a simple toml. The sample config file in the testdata folder is fairly well commented and should be enough to get you started. The configuration file is split into several sections, each of which is documented in its own page. The sections are:

Optimizing your runners

If you would like to optimize the startup time of new instance, take a look at the performance considerations page.

Write your own provider

The providers are interfaces between GARM and a particular IaaS in which we spin up GitHub Runners. These providers can be either native or external. The native providers are written in Go, and must implement the interface defined here. External providers can be written in any language, as they are in the form of an external executable that GARM calls into.

There is currently one native provider for LXD and several external providers linked above.

If you want to write your own provider, you can choose to write a native one, or implement an external one. I encourage you to opt for an external provider, as those are the easiest to write and you don't need to merge it in GARM itself to be able to use. Faster to write, faster to iterate. The LXD provider may at some point be split from GARM into it's own external project, at which point we will remove the native provider interface and only support external providers.

Please see the Writing an external provider document for details. Also, feel free to inspect the two available sample external providers in this repository.