GitHub Actions — що це таке, пайплайни CI/CD та автоматизація

Що таке GitHub Actions?

GitHub Actions — це платформа автоматизації робочих процесів, вбудована в GitHub та запущена у 2019 році. Вона дозволяє визначати пайплайни CI/CD у YAML-файлах, що зберігаються безпосередньо в репозиторії. Кожен workflow запускається за тригером: push, pull request, створення тегу або за розкладом. На відміну від Jenkins або TeamCity, не потрібна окрема інфраструктура для хостингу CI-сервера.

У контексті мобільної розробки GitHub Actions автоматизує збірку APK та IPA, запуск unit-тестів та UI-тестів на емуляторах, перевірку коду лінтерами, підпис та публікацію в Google Play та App Store. Платформа надає безкоштовні хвилини для публічних репозиторіїв та для приватних — залежно від тарифного плану. Для open-source мобільних проєктів це повноцінне CI/CD-рішення без витрат.

Архітектура GitHub Actions: Workflows, Jobs та Steps

Архітектура GitHub Actions складається з чотирьох рівнів. Workflow — це кореневий YAML-файл, що визначає автоматизацію. Workflow складається з Jobs, кожен Job виконується на окремому Runner. Усередині Job виконуються Steps — послідовні команди або зовнішні actions. Events визначають тригери запуску: push, pull_request, schedule, workflow_dispatch. Workflow може також бути викликаний вручну через вкладку Actions в інтерфейсі GitHub.

GitHub надає хостирувані runners із попередньо встановленими ОС: Ubuntu, macOS та Windows. Для iOS-збірки обов’язковий macOS-runner, для Android — Linux або macOS. Self-hosted runners дозволяють запускати jobs на власних серверах із кастомним оточенням, що корисно для великих проєктів з особливими вимогами до апаратного забезпечення. GitHub також підтримує групи self-hosted runners для організації черги виконання jobs.

Структура workflow-файлу

Базовий workflow-файл містить секції: name, on (тригери), jobs. Кожен job вказує runs-on (тип runner), strategy (матриця), steps (список дій). Steps можуть бути командами shell або готовими actions з маркетплейсу, що підключаються через синтаксис owner/repo@version.

Збірка мобільних додатків у GitHub Actions

Для Android-збірки workflow зазвичай включає кроки: checkout репозиторію, встановлення JDK, налаштування Gradle-кешу, запуск assembleRelease. Для iOS потрібен macOS-runner, встановлення Xcode через xcode-select, вирішення provisioning profile та запуск xcodebuild. Складність iOS-збірки пов’язана з code signing та управлінням сертифікатами. Специфічні для Apple налаштування включають управління provisioning profile через apple-actions/import-codesign-certs.

Matrix strategy дозволяє запускати збірку на кількох версіях одночасно. Наприклад: matrix з версіями iOS (15.0, 16.0, 17.0) та Xcode (14, 15). Це прискорює верифікацію сумісності додатку з різними версіями ОС, хоча й збільшує споживання хвилин runners. Для проєктів з обмеженим CI-бюджетом можна обмежити matrix лише основними конфігураціями.

Налаштування оточення для Android

GitHub Actions надає action setup-java для встановлення JDK та caching для кешування Gradle. Android SDK вже попередньо встановлений на Ubuntu-раннерах. Для кастомних API-рівнів використовується sdkmanager в окремому step. Рекомендується створювати окремі workflow для збірки Android та iOS, оскільки вони використовують різні runners та інструменти збірки.

GitHub Marketplace та готові actions

GitHub Marketplace містить понад 15 000 actions, створених спільнотою та офіційними розробниками. Для мобільної розробки ключові категорії: Code signing (apple-actions/import-codesign-certs), тестування (react-native-community/action), деплой (google-github-actions/release-google-play), сповіщення (slackapi/slack-github-action). Також доступні action для Firebase App Distribution, TestFlight upload та Fastlane. Кожен action має мітку сумісності з конкретною ОС runner.

Кожен action має версію, опис, README та ліцензію. При виборі action перевага надається офіційним від вендорів (Google, Apple, Microsoft) та перевіреним через Verified Badge. Важливо вказувати фіксовану мажорну версію (actions/checkout@v4), а не @main, щоб уникнути неочікуваних змін. Якщо потрібного action немає в Marketplace, можна створити кастомний action — локально в репозиторії (Docker action або JavaScript action) або опублікувати в Marketplace.

Популярні actions для CI/CD мобільних додатків

• actions/checkout — клонування репозиторію в runner
• actions/setup-java — встановлення JDK для Android-збірки
• gradle/actions/setup-gradle — налаштування та кешування Gradle
• apple-actions/import-codesign-certs — імпорт сертифікатів для iOS
• google-github-actions/submit-release — публікація в Google Play Console

Приклад workflow для iOS-проєкту

При розробці iOS-додатків важливо налаштувати коректну роботу з симуляторами та пристроями. macOS-14 runner надає середовище з Rosetta 2 для запуску Intel-збірок на ARM архітектурі. Workflow може включати кілька схем збірки — Debug для pull request та Release для тегів. GitHub Actions підтримує xcresult parsing через action xcparse/sonarqube для відображення результатів тестів. Для надсилання сповіщень про статус збірки можна додати Slack або Telegram action.

Code signing для iOS вимагає імпорту сертифікатів та provisioning profiles. Apple-actions надають step для імпорту P12 сертифіката та встановлення provisioning profile. Сертифікати зберігаються як secrets GitHub Actions та розшифровуються тільки на етапі збірки. Для автоматизації підпису використовується Fastlane match, який може бути викликаний як окремий step у workflow.

Розглянемо workflow для iOS-додатку на Swift, який збирає проєкт, запускає тести та створює архівовану збірку. Workflow використовує macOS-14 runner, Xcode 15.4 та actions для управління сертифікатами.

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

Кешування залежностей у GitHub Actions

Кешування скорочує час збірки, зберігаючи залежності між запусками workflow. GitHub надає вбудоване кешування через actions/cache. Для Gradle кешується ~/.gradle, для CocoaPods — Pods/, для SPM — .build/. Ключ кешу включає хеш файлу зі списком залежностей — при зміні залежностей кеш автоматично інвалідується.

Особливу увагу варто приділити стратегії відновлення кешу (restore-keys). Якщо точний ключ не знайдено, GitHub Actions пробує частковий збіг по restore-keys. Це корисно, коли змінюється лише одна залежність — кеш залишається частково придатним. Для Gradle додатково рекомендується увімкнути Gradle Build Cache, який кешує результати збірки між різними модулями проєкту.

Приклад кешування Gradle

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

Ефективність кешування для Android-проєктів: перша збірка без кешу — 8–12 хвилин, повторна з кешем — 2–4 хвилини. Для iOS з CocoaPods економія аналогічна. Рекомендується комбінувати actions/cache з setup-gradle action від Gradle для оптимального управління кешами. Для npm-залежностей React Native використовується actions/cache з хешуванням package-lock.json. При правильному налаштуванні кешування можна досягти скорочення часу збірки до 70%.

GitHub Actions підтримує змінні оточення на рівні workflow, job та step. Змінні оточення можна перевизначати: step-level має найвищий пріоритет. Для конфіденційних даних завжди використовуйте secrets — вони зашифровані AES-256 та не відображаються в логах. Також доступні environment protection rules — обов’язкове ручне підтвердження перед запуском деплою. Для додаткової безпеки можна налаштувати обов’язкове approval від певних користувачів або команд.

GitHub Actions також підтримує Reusable Workflows — перевикористовувані пайплайни, які можна викликати з інших workflow. Це дозволяє створити централізований workflow збірки та перевикористовувати його у всіх репозиторіях організації. Reusable workflow викликається одним рядком і може приймати вхідні параметри та secrets. Це особливо корисно для стандартизації CI/CD практик у великих командах.

Безпека та кращі практики

При налаштуванні GitHub Actions для мобільних проєктів важливо дотримуватися принципів безпеки. OIDC (OpenID Connect) дозволяє відмовитися від довгоживучих credentials та отримувати тимчасові токени для хмарних провайдерів. Ніколи не використовуйте plain-text secrets у скриптах — GitHub Actions автоматично маскує secrets в логах.

Для мобільних проєктів критично важливо обмежити доступ до workflow для сторонніх fork. Використовуйте налаштування pull_request_target з обережністю — вона виконує код з базової гілки, а не з fork. Для code signing iOS-додатків рекомендується зберігати сертифікати в зашифрованому вигляді та розшифровувати їх тільки на етапі збірки через gpg або openssl.