This is great news. The only part missing is official docker support for the runner (I'm using an unofficial solution right now) and/or Alpine support.
GitHub Actions: Ephemeral self-hosted runners and new webhooks for auto-scaling
11–20 of 74 posts
Re: GitHub Actions: Ephemeral self-hosted runners and new webhooks for auto-scaling
#12This feature was delayed every month after May.
And yet it is still half baked. We prepared for this with internally shared docs and the branch built in private for a while, but still had to roll back yesterday because the scheduler reverted to putting jobs wherever it pleased (including on ephemeral runners that already have a job) and randomly cancels large sets of jobs too.
I have been of the opinion that investing into GH Actions at this stage is purely sunken cost (at my org), and I'm not moving until the team behind this thing ships something that doesn't break half the time. These have been seriously frustrating months, because no amount of working around this messy code[1] made of 5 layers of MS style .NET (seriously, deleting a directory goes 5 layers deep in the call stack) will ever produce a stable product. They don't even know their own code base that well, when they first attempted ephemeral runners with `--once` it turned out the thing they produced could never work (because the server-side scheduler loves pipelining jobs to machines and failing miserably when these disappear, job times out after 20 minute of waiting type)
Re: GitHub Actions: Ephemeral self-hosted runners and new webhooks for auto-scaling
#13The feature pull request has been there for over a year[1], it’s nice that’s it’s released!
Incoming shameless plug; if you don’t have to handle the hosting runners, but still to reap the benefits of having proper hardware(close to the metal). Check out BuildJet for GitHub actions - 2x the speed for half the price. Easy to install and easy to revert.
[1] https://github.com/actions/runner/pull/660 [2] https://buildjet.com/for-github-actions
Re: GitHub Actions: Ephemeral self-hosted runners and new webhooks for auto-scaling
#14So this is a big step forward in terms of avoiding the race condition where CI runners would accept new jobs during scale-in operations. But how do you ensure you only spawn new ephemeral runners as jobs become available? The webhook provides part of the answer, but do we need to use something like redis to ensure exactly one runner per queued job is started?
It'd be nice if we had an API for all jobs that still need a runner, but I don't think that'll happen.
Re: GitHub Actions: Ephemeral self-hosted runners and new webhooks for auto-scaling
#15The (previous) lack of ephemeral runners was one of my few gripes with GitHub Actions, great to see it's been released!
My main grip with Github is that it's pushing more tie in features to own the development experience even further. Github started as a community development hub, now trying to swallow us all, owning each bit of the development process to then own the market. I don't have any affection for aws or gcp either, their attempt to dominate as de facto infrastructure and software provider is scary. We don't need github actio…
It's an option, nothing more.
My main gripe with it that it has the same effect as MS Teams: Execs see that a new product enters the market, with a vendor they already have agreements with, and it's either bundled in for free or relatively cheap. Being the right solution for the job has already lost at that point.
Re: GitHub Actions: Ephemeral self-hosted runners and new webhooks for auto-scaling
#16I really wish the runner agent was written in something more portable than .NET. That choice feels like something purely political because they’re owned by Microsoft. I doubt and independent organization would have chosen it before other excellent choices such as Go, Rust etc.
Currently hosting the runner on e.g. FreeBSD or custom embedded systems is not supported (or even possible).
Re: GitHub Actions: Ephemeral self-hosted runners and new webhooks for auto-scaling
#17I really wish the runner agent was written in something more portable than .NET. That choice feels like something purely political because they’re owned by Microsoft. I doubt and independent organization would have chosen it before other excellent choices such as Go, Rust etc. Currently hosting the runner on e.g. FreeBSD or custom embedded systems is not supported (or even possible).
It's not because they're owned by Microsoft, at least not in the way you think.
It's because GitHub Actions is rebranded Azure Pipelines.
That a team at GitHub has been given a pile of Microsoft authored code is honestly much more concerning. They don't seem to understand it in its entirety either.
Re: GitHub Actions: Ephemeral self-hosted runners and new webhooks for auto-scaling
#18If anyone has experience using self hosted GH Actions at scale, I’d love to buy you a virtual coffee and hear about pros/cons for a parallelized CI flow currently running in Circle. Main motivation for switching would be simplification of tooling and increasing performance with better cache reuse and running within AWS for faster network access to ECR.
At https://packhelp.com we use Github Actions for ~50 devs. I can share my experience, reach me.
Also, we have some useful Ansible scripts that I might share if there is interest
Re: GitHub Actions: Ephemeral self-hosted runners and new webhooks for auto-scaling
#19I wish there was an official Helm Chart for k8s, like GitLab CI/CD Runner has, and not the kind that sits there and does no scale, but he kind that spins up workers on demand without taking too much resources while idle.
I wish GitHub copied that feature from GitLab too!
Re: GitHub Actions: Ephemeral self-hosted runners and new webhooks for auto-scaling
#20I wish there was an official Helm Chart for k8s, like GitLab CI/CD Runner has, and not the kind that sits there and does no scale, but he kind that spins up workers on demand without taking too much resources while idle. I wish GitHub copied that feature from GitLab too!
It's not official, but there are K8s / github actions runner deployments: https://github.com/actions-runner-controller/actions-runner-...
I've been playing about with this and it seems to work quite well. Startup latency is quite high, and it's one pod-per-job (I think), but seems pretty flexible.