3 ms·
GitHub themselves don't seem to provide any mechanism to make runners ephemeral. It looks like all they allow you to do is flag a runner as ephemeral, meaning i
by jackwilsdon 3y ago
GitHub themselves don't seem to provide any mechanism to make runners ephemeral. It looks like all they allow you to do is flag a runner as ephemeral, meaning it will be de-registered once a job is completed - you need to write your own tooling to wipe it yourself (either via starting a whole new runner in a new environment and registering that or wiping the existing runner and re-registering it).
https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners#using-ephemeral-runners-for-autoscaling https://docs.github.com/en/actions/hosting-your-own-runners/...
- gz5 3y agothere are 3rd party foss options (1): 1. ephemeral + zero implicit trust (2) https://blog.openziti.io/my-intern-assignment-call-a-dark-webhook-from-aws-lambda https://blog.openziti.io/my-intern-assignment-call-a-dark-we... 2. zero implicit trust: https://github.com/openziti/ziti-webhook-action https://github.com/openziti/ziti-webhook-action (1) disclosure, maintainer (2) zero implicit trust in this case = no open inbound ports on underlay; need to access via app-specific overlay which requires strong identity, authN, authZ
- crohr 3y agoI've just made runs-on [1] for that purpose: self-hosted, ephemeral runners for GitHub Action workflows. Long-running self-hosted runners are simply too risky if your project is public. [1]: https://runs-on.com https://runs-on.com