garm v0.1.5 #285
gabriel-samfira
announced in
Announcements
garm v0.1.5
#285
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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
tov0.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:
metadata_url
,callback_url
andwebhook_url
settings have now been moved to the database in the controller table. These settings can now be updated using thegarm-cli
command line tool.garm-cli
command line tool. Details bellow.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
andself-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 multiplequeued
jobs, theroundrobin
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:
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:
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
make help
by @bavarianbidi in Introduce golangci config andmake help
#218New Contributors
Full Changelog: v0.1.4...v0.1.5
This discussion was created from the release garm v0.1.5.
Beta Was this translation helpful? Give feedback.
All reactions