GitHub Actions: automatizované testy v CI/CD pipeline

Autor:  Katarína Kučáková

Testovanie • 12 min. čítania • 5. 11. 2026

Autor:  Katarína Kučáková •

Testovanie • 12 min. čítania • 5. 11. 2026

GitHub Actions spúšťa tvoje testy automaticky pri každom push aj pull requeste, bez vlastného servera a bez DevOps tímu. Testy, ktoré sa nikdy nespustia, neexistujú. Aj tie najlepšie napísané strácajú hodnotu, ak bežia iba tesne pred releasom.

GitHub Actions tutoriály sú väčšinou písané pre vývojárov, ktorí riešia deploy a build procesy. Tento text je pre tých, ktorí chcú nastaviť automatizované testovanie v CI/CD pipeline bez toho, aby museli rozumieť celej DevOps infraštruktúre.

Čo je GitHub Actions?

GitHub Actions je CI/CD platforma integrovaná priamo v GitHube, ktorá umožňuje automatizovať spúšťanie testov, buildov a ďalších úloh bez externých nástrojov. Ak sa venuješ testovaniu, zaujíma ťa jedna vec: to, aby sa tvoje testy spustili automaticky po každom commite. Presne na to slúži. Podrobnosti k jednotlivým funkciám nájdeš v oficiálnej dokumentácii GitHub.

V praxi definuješ workflows, ktoré obsahujú viacero jobov a krokov, pričom každý krok beží na virtuálnom stroji (runneri). Aj rozsiahle testovacie sady, integračné testy alebo end-to-end testy sa dajú spúšťať automaticky a paralelne, bez ručného zásahu.

Takto zavedená nepretržitá integrácia (CI) uľahčuje sledovanie kvality kódu a umožňuje rýchlo odhaliť chyby. V kombinácii s CI/CD pipeline získava tím okamžitý prehľad o stave testov a stabilite repozitára, čím sa zrýchľuje celý vývojový proces.

Ako funguje GitHub Actions: základné pojmy

GitHub Actions stojí na štyroch pojmoch, ktoré sa v dokumentácii aj v YAML súboroch opakujú stále dokola. Keď ich raz pochopíš, konfigurácia prestane pôsobiť komplikovane.

Workflow, job, step, runner: čo je čo?

Hierarchia je jednoduchá a drží sa jedného pravidla: každá úroveň obsahuje tú nasledujúcu.

Workflow je celý automatizovaný proces, ktorý sa definuje v jednom YAML súbore. Môže napríklad spúšťať testy vždy, keď sa otvorí alebo aktualizuje pull request. Jeden repozitár môže mať viac workflows, pričom každý rieši inú situáciu.

Job je samostatná skupina krokov, ktorá beží na jednom virtuálnom stroji. Jeden workflow môže obsahovať viac jobov, ktoré sa spúšťajú paralelne alebo postupne podľa závislostí.

Step (krok) je konkrétna akcia v rámci jobu, napríklad checkout repozitára, inštalácia závislostí alebo spustenie testov. Kroky sa vykonávajú vždy v poradí, v akom sú napísané.

Runner je virtuálny stroj, na ktorom job beží. Runner je virtuálny stroj, na ktorom job beží. GitHub poskytuje GitHub-hosted runnery s Linuxom, Windowsom alebo macOS. Pri súkromných repozitároch sa ich používanie odpočítava zo zahrnutého mesačného compute kreditu podľa typu runnera.

Workflow teda obsahuje joby, joby obsahujú jednotlivé kroky a každý krok beží na runneri. Pre väčšinu testovacích sád stačí jeden job s viacerými steps.

Kedy sa workflow spúšťa? (triggers)

GitHub Actions workflow sa spustí vždy, keď nastane udalosť, ktorú si v YAML súbore zadefinuješ. Tejto udalosti sa hovorí trigger (spúšťač). Pri testovaní sú najdôležitejšie tri:

• on: push – spustí workflow po každom commite do repozitára. Vhodné pre rýchle smoke testy, ktoré overia základnú funkčnosť kódu.
• on: pull_request – spúšťa sa pri otvorení alebo aktualizácii pull requestu. Ide o klasický quality gate: merge je povolený, až keď všetky testy prejdú.
• on: schedule – umožní pravidelné spúšťanie pomocou CRON syntaxe. Vhodné pre nočné regresné sady alebo týždenné performance testy.

Triggers možno kombinovať v rámci jedného workflow. Rýchle testy spúšťaš pri push aj pull requeste, náročnejšie integračné testy len v noci cez schedule, aby nezdržiavali vývoj cez deň.

Nastav si GitHub Actions pre testovanie za 10 minút

GitHub Actions workflow je obyčajný YAML súbor uložený v adresári .github/workflows/ v koreni repozitára. Netreba inštalovať žiadny plugin ani externú službu, GitHub ho detekuje automaticky a spustí pri prvom zodpovedajúcom evente. Ak sa v práci s repozitárom ešte len rozbiehaš, pomôžu ti základné Git príkazy.

Krok 1: Vytvor adresár .github/workflows/

V koreňovom adresári repozitára vytvor túto štruktúru. Adresár .github je skrytý (začína bodkou), ale GitHub ho rozpozná automaticky.

.github/
  workflows/
    tests.yml

Krok 2: Napíš prvý workflow súbor

Nižšie je ukážka minimálneho workflow pre Python projekt s pytest. Zabezpečí, že sa testy spustia na Ubuntu vždy, keď dôjde k push alebo pull requestu do vetvy main alebo develop.

name: Run Tests
on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout kodu
        uses: actions/checkout@v4
      - name: Nastav Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - name: Instalacia zavislosti
        run: pip install -r requirements.txt
      - name: Spusti testy
        run: pytest tests/ -v

Krok 3: Commitni súbor a sleduj beh

Po commite a pushi sa workflow spustí automaticky. V záložke Actions v repozitári vidíš živý log každého kroku: čo prebieha, čo prešlo a kde presne došlo k chybe. Tento pohľad je ekvivalent terminálu na tvojom počítači, len prístupný pre celý tím odkiaľkoľvek.

Krok 4: Debuguj zlyhanie buildu

Keď workflow zlyhá, GitHub ukáže presne, ktorý step spadol a prečo. Najčastejšie príčiny pri prvom nastavení: zastaraný requirements.txt, nesprávna verzia Pythonu alebo chýbajúce testovacie závislosti. Klikni na konkrétny step v záložke Actions a prečítaj výstup, zvyčajne prvý červený riadok povie všetko.

Krok 5: Nastav quality gate pre pull requesty

Každý pull request možno nastaviť tak, aby sa nedal mergovať bez zeleného buildu. Nastavenie nájdeš v GitHube pod Settings, potom Branches a Branch protection rules. Zapíšeš konkrétnu vetvu (napríklad main) a zapneš Required status checks.

Od tohto momentu sa žiadna zmena nedostane do hlavnej vetvy skôr, než ňou prejdú automatizované testy v pipeline. Quality gate je kontrolný mechanizmus, ktorý rozhoduje, či zmena môže prejsť ďalej.

Predstav si ho ako bránu, ktorá pustí kód do main len vtedy, keď splní podmienky: prešli všetky testy, build bol úspešný a prešli aj ďalšie kontroly (lint, security). Ak niektorá z týchto podmienok zlyhá, quality gate sa zatvorí a merge nie je možný.

Automatizované testovanie v GitHub Actions: praktické príklady

Automatizované testovanie (automated testing) v GitHub Actions vyzerá v praxi vždy podobne: checkout kódu, príprava prostredia, spustenie testov, uloženie reportu. Každý YAML príklad nižšie je pripravený na priame použitie, uprav len mená krokov a príkazy podľa svojho stacku.

Spustenie unit testov v GitHub Actions

Unit testy sú rýchle a nemávajú externé závislosti, preto sa hodia na spúšťanie pri každom push. Príklad nižšie používa Java, Maven a JUnit. Akcia upload-artifact uloží testovací report, ktorý si možno stiahnuť priamo z rozhrania aj po skončení jobu.

name: Java Unit Tests
on: [push, pull_request]
jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Nastav JDK 21
        uses: actions/setup-java@v4
        with:
          java-version: '21'
          distribution: 'temurin'
      - name: Spusti unit testy
        run: mvn test
      - name: Uloz test report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: junit-report
          path: target/surefire-reports/

Dôležitý detail je if: always(). Tento riadok zabezpečí, že report sa uloží aj vtedy, keď testy zlyhajú. Bez neho by pri červenom builde chýbal kontext, čo presne spadlo a prečo. Pri testovaní je zachovanie artefaktov po neúspešnom builde rovnako dôležité ako samotné spustenie testov.

Playwright a Selenium v GitHub Actions

GitHub Actions má pre e2e frameworky natívnu podporu vrátane generovania HTML reportu so screenshotmi a trace súbormi. Playwright sa inštaluje aj s potrebnými browsermi jediným príkazom npx playwright install --with-deps. Podrobnejšie o tomto nástroji sa dočítaš v článku o Playwright.

name: Playwright E2E Tests
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Instalacia zavislosti
        run: npm ci
      - name: Instalacia Playwright browserov
        run: npx playwright install --with-deps
      - name: Spusti E2E testy
        run: npx playwright test
      - name: Nahraj Playwright report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Report sa nahrá ako artefakt a stiahneš si ho aj so screenshotmi a video nahrávkami zlyhaní. Rovnaká logika platí pre Selenium: stačí vymeniť inštalačný krok za webdriver a príkaz na spustenie testov za ten, ktorý používa tvoj projekt. Zvyšok workflow zostáva rovnaký.

Integračné testy a test reporty v GitHub Actions

Integračné testy často vyžadujú beh databázy alebo inej externej služby. GitHub Actions to rieši cez services: Docker kontajnery, ktoré bežia vedľa tvojho jobu a sú automaticky k dispozícii počas behu krokov. Po skončení jobu sa zastavia samy.

jobs:
  integration-tests:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: testpass
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run test:integration
        env:
          DATABASE_URL: postgresql://postgres:testpass@localhost:5432/test

Každá zmena v kóde sa tak overí unit testami aj voči reálnej databáze v izolovanom prostredí a výsledkom je opakovateľný build bez vedľajších efektov. Presne toto je základ, na ktorom stojí continuous testing.

GitHub Actions vs. Jenkins: čo vybrať na spúšťanie testov?

GitHub Actions a Jenkins sú dva najpopulárnejšie CI/CD nástroje, ale ich filozofia je odlišná. Otázkou nie je, ktorý je lepší, ale ktorý lepšie sedí projektu, tímu a infraštruktúrnym obmedzeniam.

Kedy zvoliť GitHub Actions:

• Projekt je v GitHube a tím má do 50 ľudí.
• Nechceš spravovať server a chceš sa sústrediť na testovanie, nie na infraštruktúru.
• Začínaš s CI/CD a potrebuješ rýchle viditeľné výsledky.
• Zahrnutý mesačný compute kredit GitHub Actions postačuje na tvoje testovacie workloady.
• Chceš natívnu integráciu s pull requestmi a code review procesom.

Kedy má zmysel Jenkins:

• Potrebuješ vlastný runner na mieru, napríklad špeciálny hardvér alebo prístup do internej siete.
• Organizácia nemôže používať cloudové CI/CD z bezpečnostných alebo právnych dôvodov.
• Máš zložité multi-pipeline zostavy s vlastnou Groovy logikou.

Ak začínaš s CI/CD alebo pracuješ na projekte hostovanom na GitHub, prvá voľba je jasná. Jenkins má miesto v enterprise prostredí s dedikovaným DevOps tímom. Ak projekt nebeží na GitHub, otázka voľby väčšinou odpadá sama. Repozitáre na GitLabe majú GitLab CI/CD priamo v platforme a konfigurujú sa v súbore .gitlab-ci.yml. Princíp ostáva rovnaký: workflow, joby, kroky a runnery, len syntax a názvy sa mierne líšia. Rozhodnutie o CI/CD nástroji tak v praxi častejšie určuje to, kde je repozitár, než technické porovnanie funkcií.

Odporúčame ti…

Viac o DevOps testovaní a jeho roli v tíme nájdeš v samostatnom článku.

GitHub Actions pricing: cena a bezplatný tier

GitHub Actions free tier pokryje väčšinu testovacích projektov bez toho, aby bolo treba čokoľvek platiť. Limity sa líšia podľa typu repozitára a plánu:

• Verejné repozitáre: neobmedzený čas behu na GitHub-hosted runners. Public open-source projekty nemávajú žiadny limit minút.
• Súkromné repozitáre (GitHub Free): plán zahŕňa mesačný kredit 12 USD na výpočtový čas v GitHub Actions. Pri štandardnom Linux runneri so sadzbou 0,006 USD za minútu to zodpovedá približne 2 000 minútam behu. Pre osobné projekty a učenie to vo väčšine prípadov postačuje.
• GitHub Pro a GitHub Team zahŕňajú mesačný kredit 18 USD na výpočtový čas v GitHub Actions, čo pri štandardnom Linux runneri zodpovedá približne 3 000 minútam. GitHub Enterprise Cloud zahŕňa kredit 300 USD, teda približne 50 000 minút na rovnakom runneri. Skutočný počet minút sa však líši podľa použitého typu runnera a jeho sadzby.

Cena výpočtového času závisí od typu runnera. Štandardný Linux runner stojí 0,006 USD za minútu, Windows 0,010 USD a macOS 0,062 USD za minútu. Ak nemáš konkrétny dôvod testovať na inom operačnom systéme, Linux runner je z týchto možností najlacnejší.

Iné CI/CD služby ako CircleCI alebo Travis CI majú porovnateľné free tiery. Oproti nim má GitHub Actions jednu výhodu, ktorá rozhoduje: nulový overhead pri integrácii, keďže už pracuješ priamo v GitHub prostredí. Netreba zvlášť nastavovať prístup k repozitáru ani spravovať API kľúče.

Odporúčame ti…

Ak ti free tier nestačí alebo potrebuješ testovať na vlastnom hardvéri, nastav si GitHub Actions self-hosted runner. Pripojí sa k repozitáru ako bežný runner, ale beží na tvojom stroji bez limitu minút, čo sa oplatí pri dlhých regresných sadách a testoch v internej sieti.

Zdieľaj článok

GitHub Actions: automatizované testy v CI/CD pipeline

O autorovi

Katarína Kučáková

Software Test Engineer

Moja cesta k testovaniu softvéru sa začala v roku 2019 až po štúdiu ekonómie a pracovných skúsenostiach v iných odvetviach. To mi pomohlo vnímať IT svet v rôznych súvislostiach. Ten totiž ponúka neustále nové výzvy, pre ktoré rada hľadám riešenia. Obľubujem oddych pri čítaní, turistiku alebo lyžovanie. LinkedIn