Робочі процеси

GitHub Actions використовує концепцію робочих процесів, тобто скриптів, які запускаються автоматично, коли відбувається певна подія (наприклад, надсилання коміту).

Кожен робочий процес GitHub Actions визначається у файлі .yml у каталозі .github/workflows. Щоб дізнатися більше про робочі процеси, звернімося до таких документів:

• Синтаксис робочого процесу
• Як вибрати, коли запускається робочий процес
• Як вибрати, де запускається робочий процес
• Як вибрати, що робить робочий процес
• Написання робочих процесів
• Найкращі практики

Спільні робочі процеси

Деякі робочі процеси використовуються спільно кількома репозиторіями.

Загальні робочі процеси

• Синхронізація міток: синхронізує мітки репозиторію з файлу

Робочі процеси для конкретного треку

• configlet: перевіряє, чи правильно структуровані файли (конфігурації) треку, як синтаксично, так і семантично
• Жоден важливий файл не змінився: коментує pull request-и, які призвели б до повторного тестування наявних рішень
• Тест: перевіряє вправи треку

Робочі процеси для інструментарію

• Розгортання: розгортає Docker-образ інструментарію треку в Docker Hub та ECR

Необовʼязкові робочі процеси

Є також робочі процеси, які треки можуть підключати за бажанням:

• Призупинення внесків спільноти: автоматично коментує нові issue та PR, створені користувачами, які не є членами GitHub-організації Exercism

Власні робочі процеси

Супровідники можуть вільно додавати власні робочі процеси до своїх репозиторіїв. Прикладами таких робочих процесів можуть бути:

• Лінтування shell-скриптів
• Автоматичне коментування pull request-ів
• І так далі.