garm v0.1.2
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
- Add more
runner/pools.go
unit tests by @mihaelabalutoiu in #110 - Fix
runner/pools.go
typo by @mihaelabalutoiu in #111 - Refactor pool manager loop by @gabriel-samfira in #112
- Use su to install the runner by @gabriel-samfira in #115
- Rotate log file on SIGHUP by @ionutbalutoiu in #116
- Add logging and fix backoff loop by @gabriel-samfira in #118
- Generate client library via swagger by @mihaelabalutoiu in #119
- Add doc about performance considerations by @SystemKeeper in #120
- Replace wait implementation with errgroup by @gabriel-samfira in #121
- Add job tracking by @gabriel-samfira in #86
- Update comment on function by @gabriel-samfira in #122
- Add entity update subcommand by @gabriel-samfira in #125
- Fix entity update by @gabriel-samfira in #124
- Add more swagger client API implementation by @ionutbalutoiu in #126
- Add swagger client auth info by @ionutbalutoiu in #127
- Set on delete for jobs by @gabriel-samfira in #128
New Contributors
- @SystemKeeper made their first contribution in #120
Full Changelog: v0.1.1...v0.1.2