v2.5.6 - Changelog

Summary

Enable IPv6 for runners. Allow to specify multiple static IPs for the managed NAT gateway. Allow filtering images based on tags. A lot of changes (again) around GitHub rate-limit handling and housekeeping mechanism.

New features

Enable IPv6 for runners (fixes #142). An IPv6 is attached for both public and private runners, with an egress ipv6 (free) gateway for private instances.
Allow to specify multiple static IPs for the managed NAT gateway (fixes #139). By default up to 2 are possible, and up to 8 when a quota increase is requested. This helps if you are launching a large number of runners in private subnets, and some external service rate-limits you based on the IP.
Allow filtering images based on a tag, in addition to the name wildcard (e.g. is-production-ready=true). Example :

# .github/runs-on.yml
images:
  custom:
    owner: "123456789"
    name: "my-org/my-image-name-*"
    arch: x64
    platform: linux
    tags:
      # filter with specific value
      is-production-ready: "true"
      # allow any value
      other-tag: "*"

Automatically bind-mount /var/lib/docker on the ephemeral instance storage, if any. Fixes #144.

Bug fixes

Escape shell special characters in env file values.
If a matching AMI cannot be found, do not retry and alert on first error.
Do not attempt to retry job if generated fleet params configuration is incorrect.
Abort early if workflow run status cannot be checked.

Fixes to avoid GitHub rate-limit issues

No longer attempt to reschedule jobs where a runner theft is suspected. Instead log a warning message telling users to make sure their jobs have unique enough labels. In some cases this was triggering useless reschedules due to GitHub not reflecting the job state quickly enough.
Fix too many GitHub calls when fetching repo config from an extends attribute (cache it).
No longer unregister runners from GitHub if API credit is lower than 2500. They will be removed by GitHub 24h later anyway.
Reorganize rate-limiters, increase DELAY_SECONDS_FOR_CHECK_BACK to 180s instead of 120s. Enable github rate-limiter, and set burst to the current number of remaining tokens.
Only attempt to finalize a job once at most. Instance will auto-terminate anyway so at worst we lose the job usage metrics in CloudWatch. But at least we don't eat into the GitHub / EC2 credits.
Set housekeeping and termination queue sizes to 1 to reduce their impact on GitHub API credits.