In GitHub, così come in Azure DevOps o in altri sistemi di CI/CD, abbiamo la possibilità di scegliere se eseguire i nostri workflow tramite degli agent (o runner) completamente gestiti dal vendor, oppure da noi stessi (o dall'organizzazione). Chiaramente la scelta di un sistema o dell'altro ha dei pro e dei contro che devono essere valutati attentamente. Tra questi, possiamo sicuramente includere il fatto che gli hosted sono gestiti, pertanto non dobbiamo occuparci di mantenere le virtual machine, il software installato sopra, fare il patching, gestire lo spazio su disco, la sicurezza e così via. D'altro canto, però, siamo, spesso, molto limitati dalla quantità di CPU, GPU o memoria delle VM che ci sono offerte: se necessitiamo di performance, la strada giusta, fino ad oggi, è sempre stata quella di optare per il mondo on-prem con una configurazione hardware ad-hoc.

GitHub ha recentemente annunciato la disponibilità di large runners, ovvero di virtual machine, sempre di tipo gestito da GitHub stesso, che però hanno un range di CPU e memoria che possono scalare fino 64 core e 256Gb di RAM (ma ci sono anche configurazioni intermedie: https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners#machine-sizes-for-larger-runners).

Queste tipologie di runner non differiscono da quelli "standard", se non per il pricing, e per questo devono essere abilitati a livello di organizzazione:

A questo punto possiamo modificare il workflow specificando il nome del runner che abbiamo scelto in fase di configurazione.

jobs:
  build:
    name: Build
    runs-on: mynewrunner
    steps:
    ...

Non solo questi runner ci consentono di avere performance maggiori, ma ci possono garantire anche un indirizzo IP statico, la possibilità di autoscaling (fino ad un limite imposto dall'organizzazione per limitare i costi) e il supporto a GPU dedicata, oltre che a runner basati su ARM.