4 ms·
The only frustrating part of this project is GitHub actions itself. It could be so much better (https://news.ycombinator.com/item?id=37612420 https://news.ycomb
by gchamonlive 3y ago
The only frustrating part of this project is GitHub actions itself. It could be so much better (https://news.ycombinator.com/item?id=37612420 https://news.ycombinator.com/item?id=37612420). Part of the hassle is figuring out why on earth actions/checkout stopped working in your self-hosted infrastructure... Why you suddenly have what once were ephemeral SQL containers persisting and blocking specific ports in subsequent runs... And why that sweet python provisioning action isn't doing its job anymore...
It all comes down to the instances. GitHub runners are insanely complex and also the best part of actions, along with community driven reusable workflows. They not only pack so much stuff without conflict, they also spin up really fast (forgot which virtualization infrastructure they use). So when you move to self-hosted you now have instances that take longer to be ready, increasing cold start times from pipelines, that will require that you install everything you need in it to run your jobs, and that, depending on how you set them, will require more thorough cleanup after each job.
The scalability is really good though, and all the benefits already cited, like having access to private resources on your VPC, and delegating permissions to instance profile through IAM roles, make this project a godsend.
- suryao 3y agoWe maintain a little action called Action-Debugger that let's you ssh into a running GitHub action workflow to help debug pesky issues. It has a few additional features when you use it with our runners but works very well by itself. https://docs.warpbuild.com/tools/action-debugger https://docs.warpbuild.com/tools/action-debugger https://github.com/WarpBuilds/action-debugger https://github.com/WarpBuilds/action-debugger