01 / Context
Quan té sentit un runner propi
Control de l'entorn
Pots treballar amb hardware, SDK, eines i serveis locals que no estan disponibles en un runner allotjat per GitHub.
Responsabilitat local
El sistema operatiu, les dependències, l'espai de disc i la higiene de la màquina passen a ser responsabilitat teva.
No és una màquina neta per job
Un self-hosted runner pot conservar estat entre execucions. No s'ha d'assumir el mateix aïllament que ofereix una màquina efímera nova.
Windows és una plataforma suportada
GitHub documenta runners self-hosted per Windows i permet configurar-los de manera interactiva o com a servei.
02 / Instal·lació
Instal·lació i servei a Windows
GitHub genera des de Settings → Actions → Runners les ordres de descàrrega, configuració i registre per al repositori o organització. El token de registre és temporal. A Windows, si vols instal·lar el runner com a servei, la configuració s'ha de fer amb privilegis d'administrador.
- Descarrega el paquet i executa la configuració des de les instruccions del repositori o organització que ha de rebre el runner.
- Si el runner funcionarà com a servei de Windows, decideix-ho durant la configuració inicial; canviar-ho després pot requerir tornar-lo a configurar.
- Mantén Windows i el software instal·lat actualitzats. GitHub actualitza l'aplicació del runner, però no administra la resta de la màquina.
- No copiïs tokens de registre ni credencials del runner a eines de monitoratge, captures o fitxers de configuració externs.
03 / Cua i etiquetes
Com s'assignen i esperen els jobs
GitHub busca un runner online i lliure que coincideixi amb els labels i grups declarats a runs-on. Si no n'hi ha cap, el job queda en cua fins que apareix un runner compatible. Aquesta lògica és important quan tens diversos runners locals o quan no vols mantenir-los tots connectats alhora.
Què convé observar en una màquina amb diversos runners
- Quins runners estan READY, BUSY, STOPPED o amb error.
- Si els labels i el destí GitHub del runner coincideixen amb els jobs que esperes executar.
- CPU, memòria i disc del host quan dos jobs competeixen pels mateixos recursos.
- Logs locals del runner quan un job no arrenca, queda penjat o acaba sense un resultat clar.
04 / Gestió local
On entra NRS Workbench
NRS Workbench no registra runners a GitHub ni substitueix la configuració oficial. Treballa sobre runners locals ja configurats i concentra el seu estat, control, diagnòstic i historial local en una aplicació Windows.
- Inici, parada i reinici de runners interactius o configurats com a servei.
- Estats locals READY, BUSY i STOPPED, més diagnòstic a partir dels fitxers del runner.
- Smart Queue opcional per mantenir un o dos runners connectats i rotar runners inactius sense interrompre intencionadament jobs actius.
- Historial basat en Worker logs locals: és historial de jobs processats pel runner, no un historial complet del compte de GitHub.
- CPU, RAM i disc del host al costat de l'activitat dels runners.
05 / Comprovació
Checklist abans de deixar-lo treballant
- 01
Confirma que el runner apareix online a GitHub i que els labels són els que utilitza el workflow.
- 02
Decideix si ha de funcionar interactiu o com a servei de Windows.
- 03
Limita qui pot executar workflows sobre aquella màquina.
- 04
Evita que dos jobs pesats saturin CPU, RAM o disc si comparteixen host.
- 05
Revisa periòdicament logs, espai lliure, actualitzacions i credencials exposades al workflow.
06 / Seguretat
Seguretat: el límit més important
GitHub adverteix que un runner self-hosted persistent pot quedar compromès si executa codi no fiable i recomana extremar la precaució amb repositoris públics. NRS Workbench no crea sandboxing ni converteix en segur executar pull requests desconegudes. La política del workflow continua sent la primera barrera.