Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
23.06.2025
Особливості кешу в GitHub Actions
В GitHub Actions кеш — це єдиний вбудований спосіб зберегти дані між збірками. На жаль, його семантика обмежена та поза тривіальним використанням дає несподівані результати.
Почнемо з того, що кешу є лише 10 Гб, зверху того все витісняється. Витісняються ті записи, що давно читалися. Все, що не читалося 7 днів, витісняється, навіть коли місце є.
Далі… ключ кешу неможливо перезаписати. Тобто щоб оновити кеш, потрібно спочатку збудувати новий ключ. Відновлення відбувається за префіксом, тобто можна прочитати крайній кеш, а потім записати новий.
А тепер, складність: ми зобовʼязані так підібрати ключі, щоб вони змінювалися не дуже часто. Якщо кожна збірка генерує новий ключ (наприклад, коли ключем буде хеш коміту) - ми швидко заповнимо всі 10 Гб, та почнемо витісняти інші, не такі часті ключі.
Інколи це легко — наприклад, взяти версію компілятора чи хеш від yarn.lock. А інколи ні — наприклад, для проміжних результатів компіляції немає що хешувати. А починати компіляцію щоразу з нуля не хочеться. Тут й опиняємось в вище згаданій ситуації.
Як компроміс, я вигадав використовувати в якості ключа дату: тоді кеш буде не старіше за день, та в нас буде не більше 7 копій одночасно.
Другий момент - до кешу не можна ставитися як до чогось передбачуваного. Це не база даних. Різні збірки можуть неочікувано отримувати різні версії кешу (тобто різні ключі за спільним префіксом.) Навіть в межах однієї збірки, кожна задача (job) самостійно звертається до кешу. Колись я хотів зберігати в кеш дані про покриття коду - це було нестабільно та постійно помилялося. Так що мусимо бути готові, що кеш буде неактуальним (або його не буде зовсім.)
Все це було б не так погано, якби збіркам було доступне інше сховище, але маємо те що маємо.