RunsOn RunsOn

v2.8.3

View on GitHub Upgrade guide

Summary

Huge improvements to tagging, magic cache is now even faster, and bug fix for jobs tied to environments with no approval required.

What's changed

QoL improvements

  • Check if the spot role exists before starting RunsOn service (preflight check 2 from the installation guide). If not, alert the user over the SNS topic.

  • Cleanup all dangling instances, irrespective of RunsOn version.

  • Rewrote magic cache to more efficiently stream uploads when actions/cache is the client. For bigger (>1GiB) payloads, there should be a very noticeable improvement.

  • If SSHAllowed is set to false at the stack level, discard any ssh=true value coming from label or repo config. Fixes #310.

Improvements to tagging

  • Pass all custom tags to volumes, in addition to instances, when creating the runner. Fixes #264.

  • Allow to set additional custom tags using a custom property in the GitHub settings of a repository. If a custom property with name runs-on-custom-tags exists, RunsOn will parse it in the same way as the stack-level custom tags, and apply them to the instance and volumes. Fixes #297.

    custom property@2x

    For instance: if the value for property runs-on-custom-tags is set to key1=val1,key2=val2 then instances and volumes will get 2 new tags (key1, key2) with their corresponding values.

    Same restrictions than stack-level tags apply. Stack-level tags take precedence over tags set in the custom property, and tags set in custom properties takes precedence over custom runner tags defined in the .github/runs-on.yml configuration.

  • Pass custom tags and default branch to runner config. And write config in /runs-on/config.json (linux), or C:\runs-on\config.json (Windows). Config can then be read by actions / scripts etc. to access all runner details easily.

Bug fixes

  • Fix the race-condition that could lead to 2 instances being started when handling jobs tied to a deployment that does not require approval.

Misc

  • Add goroutine to cleanup dangling volumes and snapshots (prepare for block-level snapshots).
  • Register waiting, in_progress, and completed webhook payloads in S3 (in addition to queued).