which is triggered on GitHub events (e.g., Pull request creation, comment on an issue, etc.) A “Workﬂow” has “Job(s)” that runs an “Action”, which is offered step ofﬁcially by third-party or by yourself.
Users doesn’t need to prepare anything (instead of money 💰) Developers GitHub Runs Workﬂow on Runners ② Operation ① Listen to a queue ( HTTP long polling) ⑤ Results & Updates Commit Status ③ Dispatch to queue GitHub Queue ④ Get event Managed by GitHub
◦ Big Sur 11 ◦ Catalina • Ubuntu ◦ 20.04 ◦ 18.04 Installed software are limited. OS Major Limitations of Cloud Hosted Runners IP addresses are not static in GitHub organization level, shared by other organizations. Can’t configure good firewall. GitHub can have IP restrictions on organization so the runners can’t access GitHub. Ref: Access GitHub Meta API for IP addresses (there are many 😄) $ curl https://api.github.com/meta Network Egress Only offers one machine type • 2 CPU core • 7GB RAM • 14GB SSD Sometimes there's too much or too little, not cost efficient. For example, big Go projects wants CPU specific machines while Next.js project wants memory specific machines. Hardware • About GitHub-hosted runners, https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners • GItHub Actions Virtual Environments, https://github.com/actions/virtual-environments
dispatches event to the GitHub queue. Developers GitHub Runs Workﬂow on Runners ② Operation ① Register runner, Listen to a queue ⑤ Results & Updates Commit Status ③ Dispatch to queue GitHub Queue ④ Get event Managed by users
Runners Two big problems: • Need to register the Runner to organization, repository, etc • Need to managed the Runner for each organizations, repository, etc Provisioning (Platform) Hard to provision the runners. Sometimes we want to offer many machine types: • Standard • CPU specific • Memory specific • “Big” machines like other cloud provider products (GCP Cloud Build, AWS EC2, etc) Provisioning (Machines) Actual metrics
level) to isolate the runners by microservices. Runs a dedicated GKE cluster with actions-runner-controller/actions-runner-controller, a Kubernetes controller to manage Self-Hosted Runners. The runners created by this controller’s CRD RunnerDeployment is backed by StatefulSets. On runner start, the runner will access the GitHub API and register the runner to the repository.
machine type (2 CPU cores, 7GB RAM, 14GB SSD) while the Self-Hosted Runners can be any machine type by adding labels. 1 CPU core 100GB RAM standard memory 20 CPU core 20GB RAM high 0.1 CPU core 1GB RAM tiny 👉 Big Next.js App 👉 Docker builds 👉 Closing stale PRs
IP restriction on GitHub Organization. Cloud Hosted Runners has wide IP range and scope to the GitHub not the organization. Like normal “microservices” Egress of Self-Hosted Runners static public IP made possible by Cloud NAT + Cloud Router.