CI — это не место для медлительности. Особенно когда билд идёт 15 минут, а запусков в день — сотни. Сейчас разберём, как оптимизировать GitHub Actions: быстрее, дешевле, эффективнее.
🔹 1. Используйте
actions/cache правильно Загрузка и компиляция зависимостей — одно из самых дорогих мест. Добавьте кэширование для
npm, pip, go mod, docker layers. Пример для Node.js:
- uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-npm-
⚠️ Не кэшируйте build-артефакты, которые зависят от среды (OS, runner version) — это приведёт к нестабильности.
🔹 2. Job matrix +
fail-fast: false = контроль над параллелизмом Matrix позволяет запускать тесты параллельно (например, разные версии Python), а
fail-fast: false не останавливает все джобы при первом фейле.
strategy:
fail-fast: false
matrix:
python-version: [3.8, 3.9, 3.10]
🔹 3. Разделяйте пайплайн на reusable workflows
Выносите повторяющуюся логику в
.github/workflows/reusable.yml и вызывайте с параметрами. Это уменьшает дублирование и ускоряет поддержку.
- uses: ./.github/workflows/reusable.yml
with:
env: staging
🔹 4. Используйте self-hosted runners, если билд тяжёлый
Если у вас сборка Docker-образов весит десятки минут — дешевле и быстрее поднять свои раннеры в EC2 или Kubernetes (особенно с GPU или кастомной средой).
📌 Попробуйте
actions-runner-controller для Kubernetes: https://github.com/actions/actions-runner-controller
🔹 5. Откажитесь от
setup-* при каждом запуске setup-node, setup-go, setup-java — удобны, но каждый раз качают и устанавливают SDK. Замените на preinstalled версии в раннерах или кэшируйте вручную.✅ Вывод:
Оптимизация GitHub Actions — это про кэш, параллельность и минимизацию накладных расходов. Даже простые изменения могут ускорить пайплайн в 2–3 раза. А главное — вы перестаёте платить за простой.
🔥 Ресурсы:
- Официальная дока по кэшу https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
#devops #девопс
Подпишись 👉@i_DevOps