#GitHubActions

😸🔐⚙️ Пара порад про налаштування GitHub Actions.

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

Провайдером навіть можна записувати файли, тобто поширювати між репозиторіями налаштування лінтерів та інші файли, що неможливо винести в залежності.

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

До речі, середовище вмикається через аргумент у workflow, тож є різні підходи до його визначення. Ну, наприклад, можна вирішити, що деплой в продакшн йде з гілки master. Тоді захищаємо master правилами, щоб не можна було писати туди напряму, а потім вказуємо в середовищі production, що воно доступне тільки з цієї гілки.

Взагалі GitHub Actions це може не найпотужніше система безперервної інтеграції, але перемагають через глибокі звʼязки з GitHub - починаючи з того, що доступні в його інтерфейсі та не потребують додаткового керування доступом. Якщо у вас є ідеї, чому може бути варто не брати GitHub Actions, а піти до конкурентів, буду радий дізнатись.

Є в мене стара, але досі корисна утиліта: split_tests. Вона, попросту, розбиває довжелезний запуск тестів на декілька паралельних потоків, за набором файлів. Так збірку довжиною в годину можна виконати навіть за 10 хвилин. (На жаль, підготовка до тестів теж займає час, тому є розумна межа на кількість потоків.)

Для того потрібний тестовий пакет, який на файли можна розбити: наприклад, RSpec, або Mocha (А ось з Go вона ще не працює, хоч на Go написана — бо Go ділить тести на модулі, а не файли.)

(🦀 Як каже аксіома, до моєї реалізації на Go є реалізація з альтернативного всесвіту на Rust: split-test. Ні, серйозно!)

Колись давно я написав цю утиліту для CircleCI. А потім невдовзі там зʼявилася вбудована команда, яка робить те саме. Потім я опинився на GitHub Actions, та утиліта знову стала до нагоди — альтернатив тут немає, а ті що є, написані або на основі моєї утиліти, або схожих.

Як воно працює. Зрозуміло що ми хочемо досягнути рівного часу виконання на кожний потік. Прийнятного результату дає розділення файлів за кількістю рядків. Звісно, трапляються аномалії, де тривалість не корелює з довжиною. Тому також можна розділяти за історичними даними за тривалістю кожного тесту. Але тоді потрібно ті дані зберігати.

Або, можна знайти аномалії вручну та викликати їх окремо. Оце на мою думку оптимальний варіант. І технічно просто, і результат надійний. Зазвичай ті “аномалії” виявляються величезними інтеграційними тестами та їх в застосунку лише декілька.

Маю таку проблему, що коли працюю з купою гілок на GitHub (тобто майже завжди), то важко встежити за результатами збірок — які можуть тривати до 20 хвилин. Хотів зробити віджет, який мені б сповіщав про завершення моїх збірок.

Інтерфейсна частина вирішується дуже легко з xbar, який я всім рекомендую — там можна написати скрипт улюбленою мовою та перетворити його текстовий вихід у віджет панелі меню macOS. Але ще залишається отримувати інформацію.

Для того в нас є два методи API. Перелічити запуски збірок для репозиторію — вертає всю потрібну інформацію. Їх навіть можна відфільтрувати за автором.

Але є нюанс. Для отримання інформації потрібний “класичний” токен авторизації з повними правами до всіх репозиторіїв — не хотілося б такий тримати відкритим. Або “fine-grained” токен — там є права тільки на читання GH Actions та тільки на конкретні репозиторії — що гарно. Але щоб бачити робочі репозиторії, він повинен належати робочій організації, на що треба ще отримати дозвіл від адміністратора. Що, як на мене, шкереберть — бо ж на класичний токен з повними привілеями дозволу не потрібно.

Друга проблема — що цей API обмежений одним репозиторієм, а в мене їх принаймні 6. Хоча 6 - це не 100, та можна всі їх опитувати по черзі. Є інший API - для сповіщень. Навіть доступний із класичним токеном з точно обмеженими правами. Але… сповіщення про збірки мають сміховинний мінімум інформації: репозиторій та текстовий опис — навіть не структурований. Навіть посилання на збірку в них немає, тому інтерфейс буде на рівні “щось десь впало, піди подивись.” (Краще, ніж нічого, звісно.)

Одним словом, наче й можна зібрати потрібний мені звіт (а саме — де тести впали, а де пройшли) - але виглядає ненадійно.

До речі, а не знаєте такого ПЗ, щоб в локальному браузері, з моєю сесією перевіряло зміст сторінки, а краще — дозволяло періодично виконувати скрипти? Бо можна було б ще з такого боку зайти.

Є в AWS офіційна “дія” для GitHub Actions, щоб розгортувати сервіси. Це чудово. От тільки якщо розгортувати достатньо багато сервісів, вона почне відвалюватися з перебільшенням обмеження на кількість. Та ніякого шляху розвʼязку — ані через GA, ані через саму дію — немає.

При тому, розвʼязок дуже простий — збільшити кількість повторних спроб. AWS CLI та всілякі SDK вміють це робити. А дія — ні. Тікет про це висить вже майже два роки. Хтось зробив виправлення, але його дедалі ігнорують.

Можна було взяти форк з виправленням, або зробити свій. Натомість я обрав структурно простіший шлях: замінити виклик дії на виклики AWS CLI. Це трохи складніше, бо прямої заміни немає, треба робити два виклики - aws ecs register-task-definition та aws deploy create-deployment. Також треба передавати дані з одного в інший та будувати JSON - що можна зробити з jq.

Зате я отримав рішення, яке побудоване на більш надійних та прозорих компонентах. Очевидно, що AWS CLI використовується на багато порядків більше, ніж це дія GitHub Actions, тому й підтримка в нього краще.

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

Та й чесно, не дуже в них хороша система для створення тих спеціальних дій. Найгірше — їх потрібно писати на JavaScript, тобто видрати шматок шелскрипта не вийде. Плюс обовʼязково треба додавати до Git повністю зібраний код дії — це наче логічно, але ускладнює розробку.

Якби зараз з нуля переписував систему CI, то орієнтувався б якомога більше на шелскрипти та доступні їм засоби спрощення (як-от звичайнісінький виклик програм, без всякої спеціальної магії.)

В GitHub Actions кеш — це єдиний вбудований спосіб зберегти дані між збірками. На жаль, його семантика обмежена та поза тривіальним використанням дає несподівані результати.

Почнемо з того, що кешу є лише 10 Гб, зверху того все витісняється. Витісняються ті записи, що давно читалися. Все, що не читалося 7 днів, витісняється, навіть коли місце є.

Далі… ключ кешу неможливо перезаписати. Тобто щоб оновити кеш, потрібно спочатку збудувати новий ключ. Відновлення відбувається за префіксом, тобто можна прочитати крайній кеш, а потім записати новий.

А тепер, складність: ми зобовʼязані так підібрати ключі, щоб вони змінювалися не дуже часто. Якщо кожна збірка генерує новий ключ (наприклад, коли ключем буде хеш коміту) - ми швидко заповнимо всі 10 Гб, та почнемо витісняти інші, не такі часті ключі.

Інколи це легко — наприклад, взяти версію компілятора чи хеш від yarn.lock. А інколи ні — наприклад, для проміжних результатів компіляції немає що хешувати. А починати компіляцію щоразу з нуля не хочеться. Тут й опиняємось в вище згаданій ситуації.

Як компроміс, я вигадав використовувати в якості ключа дату: тоді кеш буде не старіше за день, та в нас буде не більше 7 копій одночасно.

Другий момент - до кешу не можна ставитися як до чогось передбачуваного. Це не база даних. Різні збірки можуть неочікувано отримувати різні версії кешу (тобто різні ключі за спільним префіксом.) Навіть в межах однієї збірки, кожна задача (job) самостійно звертається до кешу. Колись я хотів зберігати в кеш дані про покриття коду - це було нестабільно та постійно помилялося. Так що мусимо бути готові, що кеш буде неактуальним (або його не буде зовсім.)

Все це було б не так погано, якби збіркам було доступне інше сховище, але маємо те що маємо.

Є у нас ситуація, де на GA треба обчислити diff між двома комітами. Причому вони можуть бути на абсолютно різних гілках. Як це було зробити ефективно?

Зазвичай на GitHub Actions всі використовують actions/checkout, щоб витягнути зміст репозиторію. Втім, нормально ця дія витягує тільки останній коміт (тобто глибину 1.) Бо це рятує дорогоцінні секунди. Втім, з такою глибиною цей diff ніяк не зробиш.

Можна витягнути й весь зміст — якщо передати в actions/checkout параметр fetch-depth: 0. Це задачу розвʼязує, але ціною… наразі 15 секунд очікувань. Чи можна зробити якось швидше?

Звісно. можна! Згадаймо, що в GitHub є API. А в ньому, зокрема, є й порівняння комітів. Ми користуємось цією можливістю кожен раз, як створюємо PR - але так само можна зробити й зі скрипту на CI.

Щодо доступу: в задачі GitHub Actions завжди є токен для API - він сидить в secrets.GITHUB_TOKEN. Ось тут більше про його права, але на перегляд репозиторію права точно будуть.

Отже, замість операцій з Git роблю виклик GitHub API, та отримую на виході JSON, в якому зокрема є ключ .files, де перелічені всі файли зі змінами. Та ще на відміну від Git, не треба парсити ніякі цікаві формати. Береш jq та готуєш такий результат, який потрібний.

В результаті — замість 15 секунд ну може 1-2. Дрібниця, але важлива.

Помітив ненароком, що у збірці цілих 2 з половиною хвилини займає запуск сервісів. Це, якщо не стикався, всілякі бази даних та інші залежності, які є просто контейнерами Docker, чого ніхто й не приховує.

Втім, при уважному роздивлянні виявилось, що сервіси запускаються чомусь послідовно. Хоча я звик, що Docker Compose запускає їх паралельно. Про це навіть є запит, який, чомусь мені здається, навряд чи буде виконаний, але то інша тема.

Вихід, відповідно, очевидний — замінити сервіси на Docker Compose. Кумедно, що весь блок конфігурації services буквально копіюється у docker-compose.yml практично без змін. Потім на початку збірки (другим кроком після checkout) запускаємо docker compose up --detach та бачимо запуск вже за 45 секунд. Ось так, майже без зусиль, півтори хвилини заощаджено з кожної збірки.

Різниці у використанні немає — сервіси так само будуть доступні за тими ж портами, які були налаштовані раніше. Хіба що єдиний недолік — журнал контейнерів з сервісами ми просто так не побачимо. Хоча якщо він прямо потрібний, можна ж забрати з Docker без проблем.

Окреме питання — це величезні образи залежностей, які доводиться тягнути, а саме - OpenSearch, який важить майже гігабайт. Та й запускається він повільніше за всіх. Такий він, Web Scale!

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