Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
Пости з тегом #GitHubActions
19.09.2022
Пара порад про налаштування GitHub Actions
😸🔐⚙️ Пара порад про налаштування GitHub Actions.
По-перше, у Terraform є провайдер для GitHub. Якщо у вас багато репозиторіїв, то це допоможе налаштувати їх за одною системою, а також зручно керувати доступом. Особливо це важливо для складних в настройці правилах, таких, як захист гілок.
Провайдером навіть можна записувати файли, тобто поширювати між репозиторіями налаштування лінтерів та інші файли, що неможливо винести в залежності.
По-друге, дізнався, що окрім загальних секретів, що доступні в будь-якому workflow в репозиторії, існують секрети для середовища. Це зручно, якщо для різних середовищ потрібні різні налаштування, наприклад, якщо для деплою на стейдж і на продакшн ви користуєтесь різними секретами. Це також безпечно, тому що можна обмежити, в яких гілках можна увімкнути те чи інше середовище.
До речі, середовище вмикається через аргумент у workflow, тож є різні підходи до його визначення. Ну, наприклад, можна вирішити, що деплой в продакшн йде з гілки master. Тоді захищаємо master правилами, щоб не можна було писати туди напряму, а потім вказуємо в середовищі production, що воно доступне тільки з цієї гілки.
Взагалі GitHub Actions це може не найпотужніше система безперервної інтеграції, але перемагають через глибокі звʼязки з GitHub - починаючи з того, що доступні в його інтерфейсі та не потребують додаткового керування доступом. Якщо у вас є ідеї, чому може бути варто не брати GitHub Actions, а піти до конкурентів, буду радий дізнатись.
27.06.2024
Split_tests - швидші збірки на CI
Є в мене стара, але досі корисна утиліта: split_tests. Вона, попросту, розбиває довжелезний запуск тестів на декілька паралельних потоків, за набором файлів. Так збірку довжиною в годину можна виконати навіть за 10 хвилин. (На жаль, підготовка до тестів теж займає час, тому є розумна межа на кількість потоків.)
Для того потрібний тестовий пакет, який на файли можна розбити: наприклад, RSpec, або Mocha (А ось з Go вона ще не працює, хоч на Go написана — бо Go ділить тести на модулі, а не файли.)
(🦀 Як каже аксіома, до моєї реалізації на Go є реалізація з альтернативного всесвіту на Rust: split-test. Ні, серйозно!)
Колись давно я написав цю утиліту для CircleCI. А потім невдовзі там зʼявилася вбудована команда, яка робить те саме. Потім я опинився на GitHub Actions, та утиліта знову стала до нагоди — альтернатив тут немає, а ті що є, написані або на основі моєї утиліти, або схожих.
Як воно працює. Зрозуміло що ми хочемо досягнути рівного часу виконання на кожний потік. Прийнятного результату дає розділення файлів за кількістю рядків. Звісно, трапляються аномалії, де тривалість не корелює з довжиною. Тому також можна розділяти за історичними даними за тривалістю кожного тесту. Але тоді потрібно ті дані зберігати.
Або, можна знайти аномалії вручну та викликати їх окремо. Оце на мою думку оптимальний варіант. І технічно просто, і результат надійний. Зазвичай ті “аномалії” виявляються величезними інтеграційними тестами та їх в застосунку лише декілька.
10.01.2025
Спостереження за станом збірок на GitHub Actions
Маю таку проблему, що коли працюю з купою гілок на GitHub (тобто майже завжди), то важко встежити за результатами збірок — які можуть тривати до 20 хвилин. Хотів зробити віджет, який мені б сповіщав про завершення моїх збірок.
Інтерфейсна частина вирішується дуже легко з xbar, який я всім рекомендую — там можна написати скрипт улюбленою мовою та перетворити його текстовий вихід у віджет панелі меню macOS. Але ще залишається отримувати інформацію.
Для того в нас є два методи API. Перелічити запуски збірок для репозиторію — вертає всю потрібну інформацію. Їх навіть можна відфільтрувати за автором.
Але є нюанс. Для отримання інформації потрібний “класичний” токен авторизації з повними правами до всіх репозиторіїв — не хотілося б такий тримати відкритим. Або “fine-grained” токен — там є права тільки на читання GH Actions та тільки на конкретні репозиторії — що гарно. Але щоб бачити робочі репозиторії, він повинен належати робочій організації, на що треба ще отримати дозвіл від адміністратора. Що, як на мене, шкереберть — бо ж на класичний токен з повними привілеями дозволу не потрібно.
Друга проблема — що цей API обмежений одним репозиторієм, а в мене їх принаймні 6. Хоча 6 - це не 100, та можна всі їх опитувати по черзі. Є інший API - для сповіщень. Навіть доступний із класичним токеном з точно обмеженими правами. Але… сповіщення про збірки мають сміховинний мінімум інформації: репозиторій та текстовий опис — навіть не структурований. Навіть посилання на збірку в них немає, тому інтерфейс буде на рівні “щось десь впало, піди подивись.” (Краще, ніж нічого, звісно.)
Одним словом, наче й можна зібрати потрібний мені звіт (а саме — де тести впали, а де пройшли) - але виглядає ненадійно.
До речі, а не знаєте такого ПЗ, щоб в локальному браузері, з моєю сесією перевіряло зміст сторінки, а краще — дозволяло періодично виконувати скрипти? Бо можна було б ще з такого боку зайти.
12.03.2025
Здається, починаю не любити GitHub Actions
Є в 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, то орієнтувався б якомога більше на шелскрипти та доступні їм засоби спрощення (як-от звичайнісінький виклик програм, без всякої спеціальної магії.)
23.06.2025
Особливості кешу в GitHub Actions
В GitHub Actions кеш — це єдиний вбудований спосіб зберегти дані між збірками. На жаль, його семантика обмежена та поза тривіальним використанням дає несподівані результати.
Почнемо з того, що кешу є лише 10 Гб, зверху того все витісняється. Витісняються ті записи, що давно читалися. Все, що не читалося 7 днів, витісняється, навіть коли місце є.
Далі… ключ кешу неможливо перезаписати. Тобто щоб оновити кеш, потрібно спочатку збудувати новий ключ. Відновлення відбувається за префіксом, тобто можна прочитати крайній кеш, а потім записати новий.
А тепер, складність: ми зобовʼязані так підібрати ключі, щоб вони змінювалися не дуже часто. Якщо кожна збірка генерує новий ключ (наприклад, коли ключем буде хеш коміту) - ми швидко заповнимо всі 10 Гб, та почнемо витісняти інші, не такі часті ключі.
Інколи це легко — наприклад, взяти версію компілятора чи хеш від yarn.lock. А інколи ні — наприклад, для проміжних результатів компіляції немає що хешувати. А починати компіляцію щоразу з нуля не хочеться. Тут й опиняємось в вище згаданій ситуації.
Як компроміс, я вигадав використовувати в якості ключа дату: тоді кеш буде не старіше за день, та в нас буде не більше 7 копій одночасно.
Другий момент - до кешу не можна ставитися як до чогось передбачуваного. Це не база даних. Різні збірки можуть неочікувано отримувати різні версії кешу (тобто різні ключі за спільним префіксом.) Навіть в межах однієї збірки, кожна задача (job) самостійно звертається до кешу. Колись я хотів зберігати в кеш дані про покриття коду - це було нестабільно та постійно помилялося. Так що мусимо бути готові, що кеш буде неактуальним (або його не буде зовсім.)
Все це було б не так погано, якби збіркам було доступне інше сховище, але маємо те що маємо.