GitHub Actions vs GitLab CI vs Gitea Actions v roce 2026: co zvolit pro self-hosted CI/CD

GitHub Actions vs GitLab CI vs Gitea Actions v roce 2026: co zvolit pro self-hosted CI/CD

Ve třech předchozích částech jsme udělali stejnou práci třikrát. Scénář byl pokaždé stejný: push do main, sestavení, testy, nasazení na produkci přes SSH, ověření, že aplikace naběhla. Měnila se jen platforma.

Teď se vyplatí položit tato tři řešení vedle sebe. Ne proto, abychom určili vítěze, protože žádný neexistuje: všechny tři svou práci odvedou a kteroukoli z nich lze dotáhnout do funkčního stavu. Otázka je jiná — která z nich dá vašemu konkrétnímu týmu méně zbytečné práce, s jeho kódem, požadavky a časem, který je ochoten věnovat administraci.

1.1 Co přesně srovnáváme

Podmínky jsou pro všechny tři stejné: kód v soukromém repozitáři, sestavení a deploy probíhají na vašem VPS, produkce v uzavřené síti, přístup přes SSH se samostatným uživatelem bez práv root.

Klíčová věc, kterou tato série ukázala v praxi: self-hosted runner odpovídá na otázku, kde se kód provádí, a neodpovídá na otázku, kde se ukládá. Jde o dvě různá rozhodnutí a jejich zaměňování je zdrojem většiny chyb při výběru.

2. Konfigurační soubor a struktura

2.1 Kde žije konfigurace

Rozdíl není kosmetický. Na GitHubu a Gitea leží kontroly pro pull request, noční skenování a release podle tagu v samostatných souborech, které se upravují nezávisle. Na GitLabu je jeden vstupní bod a dělení se provádí přes include, což má jiný efekt: konfiguraci lze snadno centralizovat v samostatném repozitáři šablon a připojovat k desítkám projektů.

2.2 Hierarchie

GitHub Actions a Gitea Actions mají stejnou stavbu: on → jobs → steps. Stages jako samostatná entita neexistují, pořadí se určuje přes needs.

GitLab CI je postaven jinak: stages → úlohy → script. Stages se deklarují explicitně a provádějí se sekvenčně, a uvnitř úlohy nejsou kroky — je tam seznam příkazů.

# GitHub / Gitea
jobs:
  build:
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build

# GitLab
stages: [build, test, deploy]

build:
  stage: build
  script:
    - npm ci
    - npm run build

Praktický důsledek je vidět na velkém pipeline. Stages GitLabu se čtou shora dolů jako pořadí provádění, což je pohodlné, když konfiguraci prohlíží člověk zvenčí: auditor, nový inženýr, zákazník. Model GitHubu je flexibilnější, ale abyste viděli pořadí, musíte projít řetězec needs mezi úlohami.

2.3 Prostředí úlohy

Na GitLabu se image uvádí na úrovni úlohy klíčem image, a to je základní způsob práce: úloha běží v kontejneru.

Na GitHubu a Gitea je kontejner volitelný. Ve výchozím stavu se kroky provádějí přímo na runneru, a pro spuštění v kontejneru slouží klíč container na úrovni úlohy. Potřebné verze jazyků se častěji instalují akcemi jako setup-node, setup-python a podobnými.

# GitLab: kontejner ve výchozím stavu
test:
  image: node:20
  script: [npm test]

# GitHub / Gitea: verze přes akci
jobs:
  test:
    steps:
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm test

2.4 Podmíněné spuštění

Tady se logika liší a při migraci si toto místo žádá pozornost.

Na GitHubu a Gitea se klíč if nastavuje na úlohu nebo krok a vyhodnocuje výraz:

deploy:
  if: github.ref == 'refs/heads/main'

Na GitLabu se seznam rules kontroluje shora dolů, uplatní se první shodující se pravidlo a to určuje víc než jen to, zda se úloha spustí:

deploy:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
      allow_failure: false
    - when: never

Rozdíl v možnostech: rules řeší najednou tři otázky — zda se úloha dostane do pipeline, zda bude ruční, zda blokuje výsledek. Na GitHubu a Gitea se totéž skládá z několika mechanismů: if, workflow_dispatch, environment s potvrzením.

3. Secrets a proměnné

3.1 Syntaxe

GitHub a Gitea přistupují k secrets stejně, přes kontext:

run: ./deploy.sh
env:
  KEY: ${{ secrets.SSH_PRIVATE_KEY }}

GitLab dosazuje secret jako běžnou proměnnou prostředí, bez samostatného jmenného prostoru:

script:
  - ./deploy.sh
variables:
  KEY: $SSH_PRIVATE_KEY

Za tím stojí rozdíl v modelu. Na GitHubu a Gitea je secret samostatná entita s vlastním úložištěm. Na GitLabu je to proměnná s ochrannými příznaky, a právě příznaky určují, nakolik je chráněná. Odtud hlavní pravidlo čtvrté části: Masked bez Protected nechrání před ničím vážným.

3.2 Úrovně uložení

Jeden řádek tady rozhoduje víc než zbytek. Environments v Gitea neexistují, takže oddělení přístupů mezi staging a produkcí je třeba dělat ručně: různými jmény secrets, samostatnými repozitáři nebo samostatnými runnery s různými štítky. Pro tým dvou lidí je to drobnost, pro proces, kde deploy na produkci vyžaduje potvrzení odpovědné osoby, jde o vážné omezení.

4. Runner a executor

Mechanika provádění je u všech tří stejná, a to je hlavní věc, kterou si z této série odnést. Agent se sám obrací na platformu, vezme si úlohu z fronty, provede ji a vrátí logy. Platforma nikam úlohy „netlačí", takže agent nepotřebuje otevřené vstupní porty ani veřejnou adresu.

Řádek o paralelismu má praktickou váhu při plánování serveru. Jeden agent GitHubu bere jednu úlohu, takže pro čtyři paralelní sestavení se registrují čtyři agenti. GitLab a Gitea dělají totéž jedním procesem a jedním parametrem v konfiguraci.

Řádek o Kubernetes je důležitý, pokud sestavení už žijí v clusteru. Na GitLabu je to vestavěný executor, na GitHubu samostatný kontrolér, na Gitea se musíte spokojit s kontejnery na VPS.

5. Jeden deploy, tři konfigurace

Úkol je stejný: nahrát sestavené soubory na server přes rsync a restartovat službu. Zobrazeny jsou jen bloky deploye, sestavení a testy vypadají u všech tří stejně.

5.1 GitHub Actions

deploy:
  needs: build
  runs-on: [self-hosted, linux, deploy]
  environment: production
  steps:
    - uses: actions/download-artifact@v4
      with: { name: dist, path: dist/ }

    - name: Připravit SSH
      run: |
        install -m 700 -d ~/.ssh
        install -m 600 /dev/null ~/.ssh/deploy_key
        echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/deploy_key
        echo "${{ secrets.SSH_KNOWN_HOSTS }}" > ~/.ssh/known_hosts

    - name: Nahrát a restartovat
      run: |
        rsync -az --delete -e "ssh -i ~/.ssh/deploy_key" \
          dist/ deploy@${{ secrets.DEPLOY_HOST }}:/var/www/app/
        ssh -i ~/.ssh/deploy_key deploy@${{ secrets.DEPLOY_HOST }} \
          "sudo systemctl restart app.service"

    - name: Uklidit klíč
      if: always()
      run: rm -f ~/.ssh/deploy_key

5.2 GitLab CI

deploy-production:
  stage: deploy
  tags: [self-hosted, shell]
  environment:
    name: production
    url: https://app.example.com
  dependencies: [build]
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
      allow_failure: false
  before_script:
    - chmod 600 "$SSH_PRIVATE_KEY"      # proměnná typu File
  after_script:
    - shred -u "$SSH_PRIVATE_KEY" 2>/dev/null || rm -f "$SSH_PRIVATE_KEY"
  script:
    - |
      rsync -az --delete \
        -e "ssh -i $SSH_PRIVATE_KEY -o UserKnownHostsFile=$SSH_KNOWN_HOSTS" \
        dist/ deploy@$DEPLOY_HOST:/var/www/app/
    - |
      ssh -i "$SSH_PRIVATE_KEY" -o UserKnownHostsFile="$SSH_KNOWN_HOSTS" \
        deploy@$DEPLOY_HOST "sudo systemctl restart app.service"

5.3 Gitea Actions

deploy:
  needs: build
  runs-on: deploy              # štítek host režimu
  steps:
    - uses: actions/download-artifact@v3   # v4 potřebuje GitHub API
      with: { name: dist, path: dist/ }

    - name: Připravit SSH
      run: |
        install -m 700 -d ~/.ssh
        install -m 600 /dev/null ~/.ssh/deploy_key
        echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/deploy_key
        echo "${{ secrets.SSH_KNOWN_HOSTS }}" > ~/.ssh/known_hosts

    - name: Nahrát a restartovat
      run: |
        rsync -az --delete -e "ssh -i ~/.ssh/deploy_key" \
          dist/ deploy@${{ secrets.DEPLOY_HOST }}:/var/www/app/
        ssh -i ~/.ssh/deploy_key deploy@${{ secrets.DEPLOY_HOST }} \
          "sudo systemctl restart app.service"

    - name: Uklidit klíč
      if: always()
      run: rm -f ~/.ssh/deploy_key

5.4 Co z toho je vidět

• GitHub a Gitea se téměř shodují. Rozdíly se scvrkávají na štítek v runs-on, verze akcí a absenci environment.
• GitLab si bere víc práce s klíčem na sebe. Proměnná typu File vytvoří dočasný soubor sama, takže kroky s echo nejsou potřeba.
• Ruční krok se realizuje jinak všude. Na GitLabu je to when: manual v pravidle, na GitHubu environment s revizorem, na Gitea samostatný workflow s workflow_dispatch.
• Hotové akce lákají všude. Krok s appleboy/ssh-action je kratší než ruční rsync, ale v Gitea se táhne z GitHubu, a na trvalém runneru vidí kterákoli cizí akce vaše secrets. Pro jeden rsync a jeden ssh se ta závislost nevyplatí.
• Úklid klíče je povinný všude. Prostředí na self-hosted runneru je trvalé a zapomenutý klíč zůstává dostupný další úloze, ať přijde z jakékoli větve.

6. Srovnávací tabulka

O bezplatných minutách záměrně bez čísel: tarify se mění častěji, než se aktualizují články. Celkový obrázek je stabilní — GitHub dává neomezené minuty veřejným repozitářům a omezenou kvótu soukromým, GitLab dává kvótu na bezplatném tarifu, Gitea nepočítá nic, protože všechno běží u vás. Aktuální čísla ověřte na stránkách s tarify. Hlavní je tady něco jiného: minuty na vlastním runneru se nepočítají u žádné z platforem, takže kvóta přestává být argumentem, jakmile máte vlastního agenta.

7. Pro koho se co hodí

7.1 GitHub Actions

• Projekt už je na GitHubu. Nejsilnější argument, který převáží ostatní: přesouvat repozitář kvůli CI se skoro nikdy nevyplatí.
• Open source. Veřejné repozitáře dostávají cloudová sestavení bez limitu minut a vlastní agent nepotřebují, a dokonce se nedoporučuje.
• Potřebujete hotové kroky. Marketplace řeší typické úkoly jedním řádkem: sestavení image, publikace balíčků, reporty pokrytí.
• Tým bez zkušeností s CI. Nejnižší vstupní práh: soubor se upravuje přímo v prohlížeči, chyby jsou vidět hned.

Proti: na self-hosted agentovi se opatrnost s cizími akcemi stává povinností a část toho, co je v GitLabu vestavěné (reporty, historie deployů), se musí skládat z akcí třetích stran.

7.2 GitLab CI

• Tým už je na GitLabu. Stejný argument jako výše, zrcadlově.
• Složité pipeline. Stages, graf závislostí, dceřiné pipeline a matice dávají víc kontroly u konfigurací s desítkami úloh.
• Hodně projektů se stejným nastavením. Proměnné na úrovni skupiny a include z centralizovaného repozitáře šablon znatelně šetří práci.
• Potřebujete audit a transparentnost. Explicitní pořadí stages čte člověk zvenčí bez rozplétání závislostí a historie deployů ukazuje, který commit je aktuálně na produkci.
• Kubernetes hned teď. Vestavěný executor bez samostatného kontroléru.

Proti: vlastní instalace GitLabu je znatelně těžší služba než Gitea. Pokud potřebujete spíš uzavřený okruh než složité pipeline, tato varianta je náročnější na zdroje.

7.3 Gitea Actions

• Kód nesmí opustit vaši infrastrukturu. Smluvní závazky, izolovaná síť, plná kontrola nad daty.
• Malý tým a jeden server. Git platforma a runner žijí na stejném VPS, potřeba je méně zdrojů než u GitLabu.
• Zkušenost s GitHub Actions už máte. Syntaxe se přenáší téměř celá, není potřeba se přeučovat.
• Rozpočet. Žádná platba za uživatele, jen cena serveru.

Proti: nejsou environments s potvrzením, není historie deployů, není Kubernetes a ekosystém akcí je omezený. Navíc veškerá administrace je vaše: zálohy, aktualizace, HTTPS, zrcadlo akcí pro uzavřený okruh.

8. Závěr

Série začala otázkou, co je vůbec CI/CD, a končí výběrem ze tří funkčních nástrojů. Co si z ní odnést celkově:

• Dvě různé otázky. Self-hosted runner rozhoduje o tom, kde se kód provádí. Kde se ukládá, je samostatné rozhodnutí, a jejich zaměňování je zdrojem většiny chyb při výběru platformy.
• Pokud kód může ležet v cloudu — zvolte platformu, na které už tým pracuje, a přidejte vlastního agenta. Je to nejlevnější cesta ke kontrole nad zdroji a přístupem do uzavřené sítě.
• Pokud kód musí zůstat u vás — Gitea pro malý tým, self-managed GitLab tam, kde potřebujete složité pipeline a plnou sadu vestavěných možností.
• Mechanika je všude stejná. Agent se dotazuje fronty, provede úlohu, vrátí logy. Jakmile zvládnete jednu platformu, přečtete konfigurace ostatních bez slovníku.
• Trvalé prostředí vyžaduje disciplínu. Úklid klíčů, timeouty, omezení paralelismu a opatrnost s akcemi třetích stran. To je cena za rychlost a kontrolu.

Praktický plán pro toho, kdo začíná od nuly: rozjeďte nejjednodušší dvoukrokový pipeline na aktuální platformě, dotáhněte ho do zeleného stavu, a teprve pak přidejte vlastního runnera. Deploy připojte jako poslední, až budou sestavení a testy stabilní. Tento postup dá funkční výsledek za pár dní místo pár týdnů strávených nastavováním všeho najednou.

Časté dotazy