GitHub Actions Vocabulary: CI/CD Terms for Developers (англійською)

GitHub Actions є вбудованою платформою CI/CD для репозиторіїв GitHub. Він автоматизує все, починаючи від запуску тестів на запити pull до розгортання у виробництві. Незалежно від того, пишете ви свій перший робочий потік або переглядаєте конвеєр колеги, цей словник допоможе вам зрозуміти і обговорити дії GitHub з впевненістю.

---

Основна структура

Workflow

Workflow є автоматизованим процесом, визначеним у файлі YAML у .github/workflows/. Сховище може мати декілька робочих потоків — наприклад, один для CI на запитах pull і один для розгортання на злиття до main.

«Робочий процес розгортання зазнає невдачі — давайте перевіримо вкладку Дії» «Я додам новий робочий процес, який запускає лінтер на кожному PR.»

Тригер (on:)

Ключ ** on: ** визначає, які події ** вмикають** потоки робіт. Поширені тригери включають push, pull_request, schedule (cron), workflow_dispatch (ручний) і release.

«Робочий процес запускається на push до main і на pull_request, націлюючись на main» «Додати workflow_dispatch тригер, щоб ми могли запустити розгортання вручну, коли це потрібно»

Job

** завдання ** — це набір кроків, які виконуються на одному і тому ж бігунку. Задачі у потоці робіт типово виконуються паралельно, але ви можете зробити їх послідовними за допомогою needs:.

«Розділити збірку і розгортання на окремі завдання — розгортання повинно виконуватися тільки якщо збірка успішна» “Пробна робота займає 8 хвилин. Розділимо його на матрицю, щоб різні тестові набори працювали паралельно»

Step

** Крок ** — це одне завдання у межах завдання. Кроки виконуються послідовно на одному і тому ж бігунку. Крок може або запустити команду оболонки ( run: ) або використовувати попередньо побудовану дію ( uses: ).

«Крок не вдається, тому що версія вузла неправильна — додайте крок setup-node перед ним»

Action

** Дія ** є одиницю автоматизації, яка може використовуватися повторно. GitHub надає офіційні дії (наприклад, actions/checkout, actions/setup-node ), і тисячі спільних дій доступні на GitHub Marketplace.

«Використовуйте офіційну дію actions/checkout для клонування репо в вашому робочому потоці» «Є спільна дія для розгортання на S3 — немає потреби писати скрипт оболонки самостійно»

---

Річки та водосховища

Runner

** Run ** — це сервер, який виконує завдання. GitHub надає хостовані запуски (Ubuntu, Windows, macOS). Ви також можете використовувати ** самостійно розміщені запуски ** на вашій власній інфраструктурі.

За замовчуванням завдання виконується на ubuntu-latest — вкажіть фіксовану версію, наприклад ubuntu-24.04 для відтворюваності

Самодостатній гонщик

Самовласний запуск це машина, якою ви керуєте самостійно, зареєстрована на GitHub для запуску робочих потоків. Корисно, якщо вам потрібне певне обладнання, більше енергії або доступ до приватних мережевих ресурсів.

«Ми використовуємо самостійно розміщений запуск для iOS build, тому що йому потрібна машина macOS з Xcode» «Упевніться, що самостійно розміщений runner є ефемерним — не дозволяйте стану зберігатися між запусками»

Environment

Environment в GitHub Actions визначає цілі розгортання (наприклад, staging, production ). Середовища можуть мати правила захисту — потрібні переглядачі, таймери очікування — перед тим, як буде виконано завдання розгортання.

«Продукційне середовище вимагає схвалення від двох переглядачів перед запуском завдання розгортання» «Секрети, що охоплюють середовище, доступні тільки для завдань, які спрямовані на це середовище»

---

Інформація, секрети, виходи

Secret

secret це зашифроване значення, яке зберігається в GitHub і вводиться в робочі потоки як змінна середовища. Секрети замасковані в журналах.

«Зберігати ключ API як секрет репозиторію і посилатися на нього в робочому потоці як ${{ secrets.API_KEY }}.» «Ніколи не кодуйте дані в файлі потоку роботи — завжди використовуйте секрети»

Artifact

** артефакт ** — це файл або каталог, створений потоком робіт, який ви бажаєте зберегти або спільно використовувати між завданнями. Використовуйте actions/upload-artifact для збереження і actions/download-artifact для отримання.

«Відправити вивід збирання як артефакт, щоб завдання розгортання могло завантажити його без перебудови» «Зберігати звіт про тестування як артефакт, щоб ми могли перевірити його після запуску»

GITHUB_TOKEN

** GITHUB_TOKEN ** — це автоматично створений токен, який буде доступним у кожному потоці робіт. Вона має права взаємодіяти зі сховищем — створювати випуски, надсилати коментарі PR, надсилати пакунки — без потреби у особистому токені доступу.

«Використовуйте ${{ secrets.GITHUB_TOKEN }} для автентифікації дії — немає потреби створювати PAT» «Обмежити GITHUB_TOKEN права доступу тільки до того, що потрібне потоку роботи: contents: read, packages: write.»

---

Додаткові функції

Матриця стратегії

** Матриця ** надає вам змогу виконувати завдання декілька разів з різними комбінаціями змінних, наприклад, для одночасного тестування декількох версій вузла або операційних систем.

«Ми використовуємо матрицю для запуску тестів на вузлах 18, 20 і 22 паралельно» Додати os: [ubuntu-latest, windows-latest] до матриці для лову платформ-специфічних помилок

Concurrency

Клавіша ** concurrency: ** забезпечує активність лише одного запуску потоку робіт (або групи одночасних запусків) у даний час. Корисно для розгортань, де ви не бажаєте, щоб одночасно працювало два розгортання.

«Встановити concurrency на потоку розгортання з cancel-in-progress: true, щоб новий відгук скасував попередній відгук»

Якщо умова

Умова ** if: ** для завдання або кроку керує його виконанням. Ви можете використовувати вирази, засновані на даних події, стані завдання або будь- якій контекстній змінній.

«Додати if: github.ref == 'refs/heads/main', щоб крок розгортання працював тільки на головній гілці» «Використовуйте if: failure() для запуску кроку сповіщення навіть якщо попередній крок зазнав невдачі»

Cache

Дія ** actions/cache ** зберігає і відновлює файли між запусками — зазвичай node_modules, кеши збирання або завантажені залежності. Це значно прискорює роботу.

«Кешувати каталог node_modules, використовуючи package-lock.json як ключ кешу» «Кеш застарів — ключ змінився, коли ми оновили залежність.»

Повторне використання робочого потоку

** Повторно використовуваний робочий потік ** це робочий потік, який можна викликати з іншого робочого потоку за допомогою workflow_call. Він сприяє принципам DRY (Don’t Repeat Yourself) у багатьох сховищах.

«Ми витягнули логіку збирання і тестування в поток роботи з повторним використанням у спільному platform-ci репо.» Будь-яка команда може викликати спільний поток розгортання і передати свої вхідні дані, специфічні для середовища

Композиційна діяльність

** Складена дія ** об’ єднує декілька кроків у одну дію, паковану як одиниця, яка може бути використана знову, у вашому сховищі. На відміну від потоку робіт з повторним використанням, складова дія виконується у межах виклику завдання.

«Ми створили складну дію, яка налаштовує Node, встановлює залежності і запускає lint — один виклик uses: замість трьох кроків»

OpenID Connect (англійською)

OIDC дозволяє GitHub Actions запитувати короткострокові дані про підписку від хмарних провайдерів (AWS, Azure, GCP) без зберігання довговічних секретів. Запуск здійснюється за допомогою токена JWT, який перевіряє постачальник хмарних послуг.

«Ми перейшли від статичних ключів доступу AWS до OIDC — робочий процес отримує тимчасові дані автоматично» З OIDC, немає довготривалих секретів, які можна обертати або випадково виявляти

---

Як використовувати цю функцію в прикладі

В PR обзоре:

«Робочий процес запускається на кожному відштовхуванні до кожної гілки — додайте фільтр paths:, щоб він запускався тільки при зміні відповідних файлів»

** В планах: **

«Давайте використаємо матрицю для запуску тестів інтеграції проти Postgres 15 і 16, щоб ми не були здивовані оновленням версії»

** Під час зневадження: **

“Задача розгортання пропускається — перевірте умову if:. Ймовірно, він оцінює як хибне, тому що github.ref не збігається»

** Під час створення нового проекту: **

“Спочатку додайте блок прав доступу GITHUB_TOKEN до робочого потоку — типовий є занадто дозволеним. Потім додайте політику довіри OIDC на стороні AWS»

Словник дій GitHub є необхідним для будь-якого розробника, який хоче володіти своїм конвеєром CI/CD, робити внесок у поліпшення робочого процесу, або просто розуміти, чому зелена галочка з’явилася (або не з’явилася) на їх PR.