GitHub Actions — apa itu, pipeline CI/CD dan otomatisasi

Czym jest GitHub Actions?

GitHub Actions to platforma automatyzacji przepływów pracy wbudowana w GitHub, uruchomiona w 2019 roku. Umożliwia definiowanie pipeline’ów CI/CD w plikach YAML przechowywanych bezpośrednio w repozytorium. Każdy workflow uruchamiany jest przez wyzwalacz: push, pull request, utworzenie tagu lub zgodnie z harmonogramem. W przeciwieństwie do Jenkinsa czy TeamCity, nie wymaga osobnej infrastruktury do hostowania serwera CI.

W kontekście programowania aplikacji mobilnych GitHub Actions automatyzuje kompilację APK i IPA, uruchamianie testów jednostkowych i interfejsu na emulatorach, sprawdzanie kodu linterami, podpisywanie oraz publikację w Google Play i App Store. Platforma oferuje darmowe minuty dla publicznych repozytoriów oraz dla prywatnych — w zależności od planu taryfowego. Dla projektów open-source aplikacji mobilnych jest to pełnowartościowe rozwiązanie CI/CD bez kosztów.

Architektura GitHub Actions: Workflows, Jobs i Steps

Architektura GitHub Actions składa się z czterech poziomów. Workflow to główny plik YAML definiujący automatyzację. Workflow składa się z Jobs, każde zadanie wykonywane jest na osobnym Runnerze. Wewnątrz Job wykonywane są Steps — sekwencyjne polecenia lub zewnętrzne akcje. Events określają wyzwalacze uruchomienia: push, pull_request, schedule, workflow_dispatch. Workflow może być również wywołany ręcznie przez zakładkę Actions w interfejsie GitHub.

GitHub udostępnia hostowane runnery z preinstalowanymi systemami operacyjnymi: Ubuntu, macOS i Windows. Do kompilacji iOS wymagany jest runner macOS, do Androida — Linux lub macOS. Self-hosted runners umożliwiają uruchamianie zadań na własnych serwerach z niestandardowym środowiskiem, co jest przydatne w dużych projektach ze szczególnymi wymaganiami sprzętowymi. GitHub obsługuje również grupy self-hosted runners do organizowania kolejki wykonywania zadań.

Struktura pliku workflow

Podstawowy plik workflow zawiera sekcje: name, on (wyzwalacze), jobs. Każde zadanie określa runs-on (typ runnera), strategy (macierz), steps (lista działań). Steps mogą być poleceniami shell lub gotowymi akcjami z marketplace, podłączanymi przez składnię owner/repo@version.

Kompilacja aplikacji mobilnych w GitHub Actions

W przypadku kompilacji Android workflow zazwyczaj obejmuje kroki: checkout repozytorium, instalacja JDK, konfiguracja cache’u Gradle, uruchomienie assembleRelease. Dla iOS wymagany jest runner macOS, instalacja Xcode przez xcode-select, konfiguracja provisioning profile i uruchomienie xcodebuild. Złożoność kompilacji iOS związana jest z code signing i zarządzaniem certyfikatami. Ustawienia specyficzne dla Apple obejmują zarządzanie provisioning profile przez apple-actions/import-codesign-certs.

Matrix strategy umożliwia uruchamianie kompilacji na kilku wersjach jednocześnie. Na przykład: macierz z wersjami iOS (15.0, 16.0, 17.0) i Xcode (14, 15). Przyspiesza to weryfikację zgodności aplikacji z różnymi wersjami systemów operacyjnych, choć zwiększa zużycie minut runnerów. Dla projektów z ograniczonym budżetem CI można ograniczyć macierz tylko do głównych konfiguracji.

Konfiguracja środowiska dla Android

GitHub Actions udostępnia akcję setup-java do instalacji JDK oraz caching do buforowania Gradle. Android SDK jest już preinstalowany na runnerach Ubuntu. Dla niestandardowych poziomów API używa się sdkmanager w osobnym kroku. Zaleca się tworzenie oddzielnego workflow dla kompilacji Android i iOS, ponieważ używają one różnych runnerów i narzędzi kompilacji.

GitHub Marketplace i gotowe akcje

GitHub Marketplace zawiera ponad 15 000 akcji stworzonych przez społeczność i oficjalnych programistów. Dla programowania aplikacji mobilnych kluczowe kategorie to: Code signing (apple-actions/import-codesign-certs), testowanie (react-native-community/action), wdrażanie (google-github-actions/release-google-play), powiadomienia (slackapi/slack-github-action). Dostępne są również akcje dla Firebase App Distribution, TestFlight upload i Fastlane. Każda akcja ma oznaczenie zgodności z konkretnym systemem operacyjnym runnera.

Każda akcja ma wersję, opis, README i licencję. Przy wyborze akcji preferowane są oficjalne od dostawców (Google, Apple, Microsoft) oraz zweryfikowane przez Verified Badge. Ważne jest określenie stałej głównej wersji (actions/checkout@v4), a nie @main, aby uniknąć nieoczekiwanych zmian. Jeśli potrzebna akcja nie jest dostępna w Marketplace, można stworzyć własną akcję — lokalnie w repozytorium (Docker action lub JavaScript action) lub opublikować w Marketplace.

Popularne akcje dla CI/CD aplikacji mobilnych

• actions/checkout — klonowanie repozytorium do runnera
• actions/setup-java — instalacja JDK do kompilacji Android
• gradle/actions/setup-gradle — konfiguracja i buforowanie Gradle
• apple-actions/import-codesign-certs — import certyfikatów dla iOS
• google-github-actions/submit-release — publikacja w Google Play Console

Przykład workflow dla projektu iOS

Przy tworzeniu aplikacji iOS ważne jest skonfigurowanie poprawnej pracy z symulatorami i urządzeniami. Runner macOS-14 zapewnia środowisko z Rosetta 2 do uruchamiania kompilacji Intel na architekturze ARM. Workflow może obejmować kilka schematów kompilacji — Debug dla pull request i Release dla tagów. GitHub Actions obsługuje parsowanie xcresult przez akcję xcparse/sonarqube do wyświetlania wyników testów. Do wysyłania powiadomień o statusie kompilacji można dodać akcję Slack lub Telegram.

Code signing dla iOS wymaga importu certyfikatów i provisioning profiles. Apple-actions udostępniają krok do importu certyfikatu P12 i instalacji provisioning profile. Certyfikaty są przechowywane jako sekrety GitHub Actions i odszyfrowywane tylko na etapie kompilacji. Do automatyzacji podpisu używa się Fastlane match, który może być wywołany jako osobny krok w workflow.

Rozważmy workflow dla aplikacji iOS w Swift, który kompiluje projekt, uruchamia testy i tworzy zarchiwizowaną kompilację. Workflow używa runnera macOS-14, Xcode 15.4 i akcji do zarządzania certyfikatami.

name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

Buforowanie zależności w GitHub Actions

Buforowanie skraca czas kompilacji, zachowując zależności pomiędzy uruchomieniami workflow. GitHub udostępnia wbudowane buforowanie przez actions/cache. Dla Gradle buforowany jest ~/.gradle, dla CocoaPods — Pods/, dla SPM — .build/. Klucz cache zawiera hash pliku z listą zależności — przy zmianie zależności cache jest automatycznie unieważniany.

Szczególną uwagę warto poświćić strategii przywracania cache (restore-keys). Jeśli dokładny klucz nie zostanie znaleziony, GitHub Actions próbuje częściowe dopasowanie według restore-keys. Jest to przydatne, gdy zmienia się tylko jedna zależność — cache pozostaje częściowo użyteczny. Dla Gradle dodatkowo zaleca się włączenie Gradle Build Cache, który buforuje wyniki kompilacji pomiędzy różnymi modułami projektu.

Przykład buforowania Gradle

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

Efektywność buforowania dla projektów Android: pierwsza kompilacja bez cache — 8–12 minut, powtórna z cache — 2–4 minuty. Dla iOS z CocoaPods oszczędność jest podobna. Zaleca się łączenie actions/cache z akcją setup-gradle od Gradle dla optymalnego zarządzania cache. Dla zależności npm w React Native używa się actions/cache z hashowaniem pliku package-lock.json. Przy prawidłowej konfiguracji buforowania można osiągnąć skrócenie czasu kompilacji nawet do 70%.

GitHub Actions obsługuje zmienne środowiskowe na poziomie workflow, job i step. Zmienne środowiskowe można nadpisywać: poziom step ma najwyższy priorytet. Dla poufnych danych zawsze używaj sekretów — są one szyfrowane AES-256 i nie wyświetlane w logach. Dostępne są również reguły ochrony środowiska — obowiązkowe ręczne potwierdzenie przed uruchomieniem wdrożenia. Dla dodatkowego bezpieczeństwa można skonfigurować obowiązkowe zatwierdzenie przez określonych użytkowników lub zespoły.

GitHub Actions obsługuje również Reusable Workflows — wielokrotnego użytku pipeline’y, które można wywoływać z innych workflow. Umożliwia to utworzenie scentralizowanego workflow kompilacji i wykorzystywanie go we wszystkich repozytoriach organizacji. Reusable workflow wywoływany jest jedną linią i może przyjmować parametry wejściowe i sekrety. Jest to szczególnie przydatne do standaryzacji praktyk CI/CD w dużych zespołach.

Bezpieczeństwo i najlepsze praktyki

Przy konfiguracji GitHub Actions dla projektów mobilnych ważne jest przestrzeganie zasad bezpieczeństwa. OIDC (OpenID Connect) umożliwia rezygnację z długowiecznych poświadczeń i uzyskiwanie tymczasowych tokenów dla dostawców chmurowych. Nigdy nie używaj sekretów w postaci zwykłego tekstu w skryptach — GitHub Actions automatycznie maskuje sekrety w logach.

Dla projektów mobilnych krytycznie ważne jest ograniczenie dostępu do workflow dla zewnętrznych forków. Używaj ustawienia pull_request_target z ostrożnością — wykonuje ono kod z bazowej gałęzi, a nie z forka. Do code signing aplikacji iOS zaleca się przechowywanie certyfikatów w zaszyfrowanej formie i odszyfrowywanie ich tylko na etapie kompilacji przez gpg lub openssl.