В пайплайне GitHub Actions настроено кэширование зависимостей. Объясните, зачем это нужно и что может пойти не так

Короткий ответ

Кэширование сохраняет скачанные зависимости (например, `node_modules`) между запусками пайплайна по ключу, обычно построенному на хэше lock-файла, чтобы не скачивать их заново при каждом запуске и ускорить сборку; риск — использование устаревшего кэша, если ключ не меняется при изменении зависимостей.

Как это работает подробнее

`actions/cache` сохраняет указанную директорию в облачном хранилище Actions и восстанавливает её в начале следующего запуска, если найден кэш с совпадающим (или ближайшим по `restore-keys`) ключом. Ключ обычно включает хэш `package-lock.json`, чтобы кэш инвалидировался при изменении зависимостей.

Пример кода

example.yamlКопировать

- uses: actions/cache@v4
  with:
    path: node_modules
    key: node-modules-${{ hashFiles('package-lock.json') }}
    restore-keys: |
      node-modules-

Что использовать на практике

• На практике. кэширование особенно полезно для сборок с большим количеством зависимостей (node_modules, Maven `.m2`, pip-пакеты), где загрузка занимает заметную часть времени пайплайна. Важно выбирать ключ так, чтобы он менялся ровно тогда, когда меняется содержимое зависимостей, а не чаще и не реже.
• Пример. Ожидаемое поведение: при неизменном `package-lock.json` повторный запуск пайплайна показывает в логе `Cache restored successfully` и пропускает длительную установку пакетов; после изменения lock-файла ключ меняется, и зависимости устанавливаются заново.

Подводные камни

• Частые ошибки. используют слишком общий ключ (например, просто `cache-node`), из-за чего при обновлении зависимости в `package.json` пайплайн продолжает использовать старый кэш и собирает проект с устаревшими пакетами; либо наоборот, включают в ключ что-то постоянно меняющееся (например, `github.sha`), из-за чего кэш никогда не переиспользуется и теряет смысл.