Czym jest GitHub Actions?

GitHub Actions to platforma do automatyzacji przepływów pracy (workflows), która jest głęboko zintegrowana z ekosystemem GitHub. Wprowadzona oficjalnie w 2019 roku, szybko stała się jednym z najpopularniejszych narzędzi CI/CD (Continuous Integration / Continuous Deployment) na rynku. Dzięki niej możesz automatycznie budować, testować i wdrażać swój kod za każdym razem, gdy zajdzie określone zdarzenie w repozytorium – na przykład push, pull request czy utworzenie nowego tagu.

Największą zaletą GitHub Actions jest fakt, że nie wymaga instalacji żadnych zewnętrznych narzędzi ani konfiguracji osobnych serwisów. Wszystko dzieje się bezpośrednio w GitHub, a konfiguracja jest przechowywana w plikach YAML w samym repozytorium. To podejście zgodne z zasadą Infrastructure as Code, co sprawia, że cała historia zmian w konfiguracji CI/CD jest śledzona razem z kodem źródłowym.

Podstawowe pojęcia – słownik GitHub Actions

Zanim przejdziesz do pisania własnych workflows, warto zapoznać się z kluczowymi pojęciami:

  • Workflow – zautomatyzowany proces zdefiniowany w pliku YAML, przechowywany w katalogu .github/workflows/.
  • Event (zdarzenie) – wyzwalacz uruchamiający workflow, np. push, pull_request, schedule czy workflow_dispatch.
  • Job – zestaw kroków (steps) wykonywanych na tej samej maszynie wirtualnej (runner).
  • Step – pojedyncza akcja lub polecenie shell wykonywane w ramach joba.
  • Action – gotowa, wielokrotnego użytku jednostka logiki, którą możesz wykorzystać w swoim workflow (np. actions/checkout).
  • Runner – maszyna wirtualna (lub fizyczna), na której wykonuje się workflow. GitHub oferuje darmowe runnery z systemami Ubuntu, Windows i macOS.

Twój pierwszy workflow – krok po kroku

Stworzenie pierwszego workflow jest zaskakująco proste. Wystarczy, że w swoim repozytorium utworzysz plik w ścieżce .github/workflows/ci.yml. Poniżej znajdziesz przykład prostego workflow dla projektu Node.js:

name: CI Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout kodu
        uses: actions/checkout@v4

      - name: Konfiguracja Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Instalacja zależności
        run: npm ci

      - name: Uruchomienie testów
        run: npm test

      - name: Budowanie projektu
        run: npm run build

Ten prosty workflow robi kilka ważnych rzeczy: pobiera kod z repozytorium, instaluje odpowiednią wersję Node.js, instaluje zależności z cache'owaniem (co znacznie przyspiesza kolejne uruchomienia) oraz uruchamia testy i buduje projekt.

Wyzwalacze – kiedy uruchamia się workflow?

GitHub Actions oferuje bogaty zestaw zdarzeń, które mogą wyzwalać workflow. Oto najczęściej używane:

  • push – uruchamia workflow przy każdym pushu do repozytorium. Możesz ograniczyć do wybranych gałęzi lub ścieżek plików.
  • pull_request – uruchamia przy otwarciu, zaktualizowaniu lub zamknięciu pull requesta.
  • schedule – uruchamia workflow według harmonogramu (cron). Świetne do nocnych buildów lub regularnych raportów.
  • workflow_dispatch – pozwala na ręczne uruchomienie workflow z interfejsu GitHub lub przez API.
  • release – uruchamia przy tworzeniu nowego release'u w repozytorium.

Możesz też łączyć wiele wyzwalaczy w jednym workflow, co daje dużą elastyczność. Na przykład możesz uruchamiać testy przy każdym pushu, ale deploy przeprowadzać tylko przy tworzeniu tagu lub release'u.

Zmienne środowiskowe i sekrety

Prawdziwe projekty produkcyjne wymagają dostępu do poufnych danych – kluczy API, tokenów dostępu, haseł do baz danych. GitHub Actions oferuje do tego celu mechanizm Secrets. Sekrety są szyfrowane i nigdy nie pojawiają się w logach workflow.

Aby dodać sekret, przejdź do Settings → Secrets and variables → Actions w swoim repozytorium. Następnie możesz użyć go w workflow w następujący sposób:

- name: Deploy na serwer
  env:
    DEPLOY_KEY: ${{ secrets.DEPLOY_SSH_KEY }}
    API_TOKEN: ${{ secrets.PRODUCTION_API_TOKEN }}
  run: ./scripts/deploy.sh

Oprócz sekretów możesz korzystać ze zmiennych środowiskowych na poziomie workflow, joba lub pojedynczego kroku. Możesz też używać wbudowanych zmiennych GitHub, takich jak ${{ github.sha }} (hash commita), ${{ github.actor }} (użytkownik) czy ${{ github.ref }} (gałąź/tag).

Macierz testów – testuj na wielu środowiskach jednocześnie

Jedną z najciekawszych funkcji GitHub Actions jest matrix strategy, która pozwala uruchamiać ten sam job z różnymi kombinacjami parametrów. To idealne rozwiązanie, gdy chcesz przetestować swój kod na różnych wersjach języka programowania lub różnych systemach operacyjnych.

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node-version: [18, 20, 22]

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

Powyższa konfiguracja uruchomi 9 równoległych jobów (3 systemy × 3 wersje Node.js), co pozwoli upewnić się, że kod działa poprawnie we wszystkich kombinacjach. Macierz może zawierać dowolne parametry i być bardzo rozbudowana.

Gotowe akcje z GitHub Marketplace

GitHub Marketplace to prawdziwa skarbnica gotowych akcji stworzonych przez społeczność i firmy trzecie. Zamiast pisać wszystko od zera, możesz skorzystać z tysięcy gotowych rozwiązań. Oto kilka przykładów popularnych akcji:

  • actions/checkout – pobiera kod z repozytorium (niezbędna w niemal każdym workflow).
  • actions/cache – cachuje zależności i inne pliki, przyspieszając workflow.
  • docker/build-push-action – buduje i publikuje obrazy Docker.
  • aws-actions/configure-aws-credentials – konfiguruje dostęp do AWS.
  • peaceiris/actions-gh-pages – publikuje statyczne strony na GitHub Pages.
  • codecov/codecov-action – wysyła raporty pokrycia kodu do serwisu Codecov.

Korzystając z akcji innych twórców, zawsze zwracaj uwagę na wersję (zalecane jest używanie konkretnego commita lub tagu, np. @v4), a nie @latest, co chroni przed nieoczekiwanymi zmianami.

Pipeline CI/CD dla aplikacji Docker

Poniżej znajdziesz bardziej zaawansowany przykład – kompletny pipeline CI/CD dla aplikacji kontenerowej, który buduje obraz Docker i wdraża go na środowisko produkcyjne:

name: Build and Deploy

on:
  push:
    tags:
      - 'v*'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Logowanie do Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_TOKEN }}

      - name: Budowanie i push obrazu
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: myapp:${{ github.ref_name }}

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Deploy przez SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            docker pull myapp:${{ github.ref_name }}
            docker stop myapp || true
            docker run -d --name myapp -p 80:3000 myapp:${{ github.ref_name }}

Zauważ użycie słowa kluczowego needs – job deploy uruchomi się dopiero po pomyślnym zakończeniu joba build. Dzięki temu mamy gwarancję sekwencyjności krytycznych kroków.

Dobre praktyki – jak pisać lepsze workflows?

Aby Twoje workflows były efektywne, bezpieczne i łatwe w utrzymaniu, warto stosować się do kilku zasad:

  1. Używaj cache'owania – akcja actions/cache lub wbudowane opcje cache w akcjach jak setup-node mogą drastycznie skrócić czas wykonania workflow.
  2. Ogranicz uprawnienia – korzystaj z zasady minimalnych uprawnień (permissions) dla tokenów GITHUB_TOKEN.
  3. Używaj środowisk (Environments) – mechanizm Environments pozwala na definiowanie reguł ochrony, wymaganych recenzentów i sekretów specyficznych dla środowisk (staging, production).
  4. Nie hardkoduj wartości – korzystaj z sekretów i zmiennych środowiskowych zamiast wpisywać wrażliwe dane bezpośrednio w plikach YAML.
  5. Monitoruj czas wykonania – długie workflows generują koszty (na płatnych planach) i spowalniają feedback loop. Regularnie optymalizuj swoje przepływy.
  6. Korzystaj z reużywalnych workflows – jeśli masz wiele repozytoriów z podobną konfiguracją CI, stwórz workflow wielokrotnego użytku (reusable workflows) w osobnym repozytorium.

Plany i cennik – czy GitHub Actions jest darmowy?

GitHub Actions oferuje darmowy przydział minut dla wszystkich użytkowników:

  • Plan Free – 2000 minut miesięcznie dla repozytoriów publicznych (bez limitu!) i prywatnych.
  • Plan Pro – 3000 minut miesięcznie.
  • Plan Team – 3000 minut miesięcznie na użytkownika.

Warto pamiętać, że minuty na systemach Windows są rozliczane dwukrotnie, a na macOS – dziesięciokrotnie w porównaniu do Ubuntu. Repozytoria publiczne korzystają z runnerów GitHub za darmo bez żadnych limitów minut, co czyni GitHub Actions szczególnie atrakcyjnym dla projektów open source.

Podsumowanie

GitHub Actions to narzędzie, które demokratyzuje dostęp do profesjonalnego CI/CD. Niezależnie od tego, czy pracujesz nad prostym projektem hobby, czy nad rozbudowaną aplikacją enterprise, GitHub Actions oferuje elastyczność i możliwości, które pozwolą Ci zautomatyzować niemal każdy aspekt wytwarzania oprogramowania. Integracja z ekosystemem GitHub, bogata biblioteka gotowych akcji oraz przejrzysta składnia YAML sprawiają, że bariera wejścia jest bardzo niska, a możliwości – niemal nieograniczone.

Zacznij od prostego workflow do uruchamiania testów, a z czasem rozbudowuj go o kolejne etapy – linting, testy bezpieczeństwa, automatyczne release'y i wdrożenia. Twój kod i Twój zespół na tym skorzystają.