GitHub Actions как кэшировать зависимости npm и Docker слои для ускорения CI

[bunmaker]

CI-пайплайн на GitHub Actions занимает 15 минут: 5 из них уходит на npm install и ещё 4 на docker build. Каждый пуш — полная пересборка с нуля. Читал про кэширование, но не очень понимаю как правильно настроить кэш для npm и для Docker-слоёв. Кто настраивал — поделитесь рабочим конфигом?

[Omoto]

Для npm проще всего использовать actions/setup-node с встроенным кэшем: - uses: actions/setup-node@v4 with: node-version: '20' cache: 'npm'. Это автоматически кэширует ~/.npm по хэшу package-lock.json. Если cache hit — npm install занимает секунды вместо минут. Для yarn и pnpm аналогично, просто меняй значение cache.

[valru]

Docker-слои кэшируются через buildx и cache-to/cache-from. Вот рабочий кусок: - uses: docker/setup-buildx-action@v3 - uses: docker/build-push-action@v5 with: context: . push: true tags: myimage:latest cache-from: type=gha cache-to: type=gha,mode=max. Ключевое — type=gha использует GitHub Actions Cache API, это работает из коробки без внешнего registry. mode=max кэширует все промежуточные слои.

[lorenzinoarq]

Развёрнутое решение по оптимизации времени CI. Для npm: помимо кэша install, стоит разделить install и build на отдельные джобы если у вас monorepo, и использовать nx affected или turborepo чтобы собирать только изменившиеся пакеты. Экономия может быть колоссальной. Для Docker: самое важное — правильный порядок слоёв в Dockerfile. Сначала копируй package.json и package-lock.json, делай npm install, и только потом COPY . . с исходниками. Тогда слой с зависимостями будет закэширован и пересобираться только при изменении package.json. Пример: COPY package*.json ./ ; RUN npm ci --only=production ; COPY src/ ./src/. Дополнительно: используй multi-stage build чтобы финальный образ не тащил devDependencies и build-tooling. Это уменьшает размер образа в 2-5 раз и ускоряет push. Ещё трюк: можно вынести тесты в отдельный job с matrix strategy и запускать параллельно — суммарное время падает кратно числу параллельных воркеров.

[sneeke]

Не забывай про cache key стратегию. Я использую такой подход: key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} restore-keys: | ${{ runner.os }}-node-. restore-keys позволяет использовать частично устаревший кэш если точного совпадения нет, вместо полного cache miss.

[timur12]

После всех оптимизаций у нас CI упал с 18 минут до 4. Ключевые вещи которые дали наибольший выигрыш по порядку: правильный порядок слоёв Dockerfile (+6 мин), кэш npm (+4 мин), параллельные тесты (+3 мин), buildx кэш (+1 мин).

[guardia]

Кстати, если часто меняются только тесты или документация, можно добавить paths filter: on: push: paths: - 'src/**' - 'package*.json' и не запускать тяжёлый пайплайн на правки в README или .md файлах.

[wasonga2]

а вы npm ci используете или npm install? пять минут на установку это подозрительно даже без кэша. ci с прогретым ~/.npm у нас на проекте с 1800 пакетами укладывается в 40-50 секунд. если в логах до сих пор npm install, начните с этого, заодно lock-файл честнее соблюдается.

[puto]

@valru, type=gha рабочий, но есть грабли: лимит кэша 10 ГБ на репозиторий. mode=max на жирном мультистейдже забивает его за несколько дней, гитхаб начинает вытеснять старые записи и hit rate проседает в ноль. Мы плюнули и перешли на type=registry с отдельным тегом buildcache в том же ghcr, живет заметно стабильнее.

[togashi]

@timur12, цифры подозрительно ровно бьются, 6+4+3+1 ровно 14 и итог ровно 4. в жизни порядок слоев и buildx кэш экономят наполовину одно и то же, эффекты пересекаются. не то чтобы не верю, но выглядит как слайд для менеджмента, лол