GitHub Actions self-hosted runner pre celú firmu

GitHub Actions self-hosted runner je stroj, ktorý spravujete vy a ktorý berie úlohy z vašich workflowov. My máme jeden pre celú organizáciu. Každý repozitár si ho vyberá jednou premennou organizácie a bez nej sa vráti na hostované runnery od GitHubu.

Funguje to vďaka trom rozhodnutiam. Runner je zaregistrovaný na úrovni organizácie, nie pri jednom repozitári. Nemá prístup k Docker socketu, a to zámerne. A repozitáre, ktoré patria našim klientom, na ňom nikdy nebežia.

Čo je self-hosted runner a kedy sa oplatí?

Hostované runnery od GitHubu sú čerstvé virtuálky, ktoré GitHub spustí pre každú úlohu. Self-hosted runner je váš vlastný stroj s runner aplikáciou od GitHubu. Nainštalujete ho, aktualizujete a rozhodujete, kam sa dostane.

Self-hosted runner sa oplatí, keď úlohy bežia často, keď potrebujú niečo, čo hostovaný image nemá, alebo keď by dlhé úlohy agentov minuli hostované minúty. U nás rozhodli posledné dva dôvody. Naše CI spúšťa pri väčšine pull requestov validátor, AI code review a AI overenie, a to v mnohých repozitároch.

Ako vyberáme runner pre každý repozitár?

Runner nemenujeme v žiadnom workflowe. Každá šablóna workflowu má rovnaký riadok. Krok validate v ňom pochádza z wizrd, nášho interného pluginu a CLI pre Claude Code (nie je verejný), a rovnaký vzor funguje aj s vašou vlastnou action:

jobs:
  validate:
    runs-on: ${{ vars.CI_RUNNER_LABEL || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v4
      - uses: Digitaliko/wizrd/.github/actions/validate@v1

CI_RUNNER_LABEL je premenná organizácie s hodnotou self-hosted, viditeľná pre všetky repozitáre. Keď je nastavená, úloha ide na náš runner. Keď chýba, výraz sa vráti na ubuntu-latest.

Práve o ten návrat ide. Keď box spadne, jedna úprava premennej pošle všetky repozitáre späť na hostované runnery. Nikto neupravuje ani jeden súbor s workflowom.

Nastavenie malo štyri kroky:

GitHub túto možnosť opisuje priamo: runnery pridané „at the organization level, where they can be used to process jobs for multiple repositories in an organization“ (GitHub docs, stav 24. 10. 2026).

Prečo sme runneru zobrali Docker?

Lebo CI runner spúšťa kód z pull requestov. GitHub to hovorí bez okolkov:

S Docker socketom je to ešte horšie. Bezpečnostná stránka Dockeru píše „only trusted users should be allowed to control your Docker daemon“, lebo kontajner si môže pripojiť koreňový adresár hostiteľa (Docker docs, stav 24. 10. 2026). Krok workflowu, ktorý sa k socketu dostane, taký kontajner spustí a stane sa rootom na boxe.

Preto sme 28. 9. 2026 socket hostiteľa z runnerov odpojili. Úlohy, ktoré potrebovali service kontajnery, začali padať na Initialize containers. Úprimne: ich CI bolo červené už týždne predtým a nikto si to nevšimol. Zmenila sa len chybová hláška.

Čo na runneri beží a čo nie?

Len CI a práca agentov: validátor, AI code review, AI overenie a kroky nášho pipeline pre agentov. Produkcia nie. Ako krok overenia posudzuje pull request, píšeme v článku LLM as a judge.

Produkčné webové servery sú samostatný stroj. Pri jednom klientskom projekte kedysi bežali buildy vedľa produkcie, a keď sa presunuli preč, produkciu sa dalo zmenšiť. Vrátiť CI vedľa nej by vrátilo aj súboj o výkon, ktorý ten presun vyriešil.

Samotný runner zostáva holý. Naša verify action začína takto, lebo recenzent potrebuje Node a skripty repozitára svoj package manager:

steps:
  # the self-hosted runner is bare: the reviewer needs node, the repo scripts need their package manager
  - uses: actions/setup-node@v4
    with:
      node-version: 22
  - uses: oven-sh/setup-bun@v2
  - shell: bash
    run: corepack enable

Každá úloha si deklaruje, čo potrebuje. Úloha, ktorá funguje na našom runneri, funguje aj na ubuntu-latest. Vďaka tomu je návrat bezpečný.

Prečo repozitáre klientov zostávajú na hostovaných runneroch?

Niektoré repozitáre patria našim klientom a sú v ich vlastnej GitHub organizácii. Ich workflowy nechávajú runs-on: ubuntu-latest. Má to tri dôvody:

• Je to ich kód a ich CI. Klient, ktorý vlastní repozitár, nemá závisieť od stroja, ktorý prevádzkujeme my. Ak spolupráca skončí, ich CI beží ďalej bez jedinej zmeny.
• Náš runner žije v našej organizácii. Runner organizácie obsluhuje repozitáre tej organizácie. Siahnuť cez hranicu organizácií by znamenalo druhú registráciu a druhú hranicu dôvery.
• Menej vysvetľovania. Nikto sa nemusí pýtať, na čom a kde beží jeho kód.

Pravidlo máme zapísané v dokumentácii k validácii. Repozitáre v našej organizácii idú podľa premennej organizácie. Servisné repozitáre klientov zostávajú na ubuntu-latest.

Hodí sa self-hosted runner vašej firme?

Prejdite si, čo máte dnes:

Posledný bod je limit, ktorý zabolí ako prvý. Jeden proces runnera berie jednu úlohu naraz a všetko ostatné čaká. Krátke úlohy to skryjú. Dlhé úlohy agentov nie. Viac procesov runnera na tom istom boxe je lacnejšie riešenie než väčší stroj.

AI review každého pull requestu, ktoré beží na našom runneri, opisujeme v článku AI code review s Claude Code v CI. Ako ďaleko púšťame agenta na jeho vlastnom stroji, je v článku Claude Code permissions: kedy je skip permissions bezpečné?

Potrebujete CI, na ktoré sa spolieha celý tím aj jeho agenti?

Runnery, zdieľané CI actions a review okolo nich nastavujeme vývojovým tímom v rámci služby seniorský vývojár do tímu. Stranu agentov pokrýva AI-native SDLC pre vývojové tímy. AI dnes píše všetok náš kód a za výsledok ručí senior. Od roku 2023 sme dodali 15+ produkčných projektov.

Ozveme sa do dvoch pracovných dní a spolu vyberieme, čo vyriešime ako prvé.

Ak sa chcete najprv porozprávať, dohodnite si meeting na 15 minút s Filipom.

Keby váš runner dnes v noci spadol, koľko súborov s workflowmi by ste zajtra museli upraviť?

Časté otázky

Čo je GitHub Actions self-hosted runner?

Stroj, ktorý spravujete vy. Beží na ňom runner aplikácia GitHub Actions, ktorá berie úlohy z vašich workflowov. Môže to byť server v cloude, virtuálka alebo počítač v kancelárii. Vo workflowe ho vyberiete cez runs-on a jeho labely.

Môže jeden self-hosted runner obsluhovať všetky repozitáre organizácie?

Áno. Runner zaregistrovaný na úrovni organizácie spracúva úlohy pre viac repozitárov v tejto organizácii. Cez runner groups obmedzíte, ktoré repozitáre ho smú používať.

Je self-hosted runner bezpečný pre verejné repozitáre?

GitHub píše, že self-hosted runnery by sa takmer nikdy nemali používať pre verejné repozitáre, lebo ktokoľvek otvorí pull request a spustí kód na vašom stroji. Aj pri súkromných repozitároch tam môže spustiť kód každý, kto smie otvoriť pull request.

Ako prepnúť medzi self-hosted a hostovaným runnerom od GitHubu?

Výrazom v runs-on: runs-on: ${{ vars.CI_RUNNER_LABEL || 'ubuntu-latest' }}. Keď je premenná nastavená, úlohy idú na váš runner. Keď nie je, vrátia sa na hostovaný Ubuntu od GitHubu. Jedna úprava premennej organizácie presunie všetky repozitáre.

Prečo nepripojiť do runnera Docker socket?

Kto môže hovoriť s Docker daemonom, spustí kontajner s pripojeným súborovým systémom hostiteľa a stane sa rootom na stroji. Na CI runneri je to každý, kto otvorí pull request. Ak úloha potrebuje kontajnery, dajte jej vlastný daemon.