Кэширование зависимостей

Кэширование зависимостей — один из самых эффективных способов ускорения CI/CD пайплайнов. Правильная настройка кэша сокращает время сборок в 2–5 раз.

#Зачем нужно кэширование?

Каждый запуск пайплайна начинается с установки зависимостей. Без кэша:

# Без кэширования — каждый раз заново
steps:
  - uses: actions/checkout@v4
  - run: npm install  # 2–5 минут каждый раз!
  - run: npm test

Проблемы без кэша:

Установка npm-пакетов: 2–5 минут
Установка pip-пакетов: 1–3 минуты
Установка Maven-зависимостей: 3–10 минут
Нагрузка на сеть и внешние реестры
Риск временной недоступности реестров

С кэшем:

Восстановление кэша: 10–30 секунд
Установка только новых зависимостей
Стабильное время сборки

#Кэширование в GitHub Actions

#actions/cache

Официальное действие для кэширования:

steps:
  - name: Cache npm dependencies
    uses: actions/cache@v4
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-

Параметры:

path — файлы или директории для кэширования
key — уникальный идентификатор кэша
restore-keys — альтернативные ключи для частичного совпадения

#Как работает ключ кэша

Ключ должен:

Быть уникальным для разных конфигураций
Изменяться при изменении зависимостей
Включать ОС для разделения кэшей между платформами

# Хороший ключ
key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}

# Плохой ключ — не меняется при изменении зависимостей
key: npm-cache-v1

# Плохой ключ — один кэш для всех ОС
key: npm-${{ hashFiles('**/package-lock.json') }}

#restore-keys для частичного совпадения

Если точный ключ не найден, GitHub проверяет restore-keys:

steps:
  - uses: actions/cache@v4
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-

Сценарий:

Зависимости изменились → точный ключ не найден
GitHub ищет кэш с префиксом ${{ runner.os }}-npm-
Находит старый кэш → восстанавливает
npm install обновляет только изменившиеся пакеты

#Кэширование npm

name: Node.js CI with cache

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'  # Встроенное кэширование!

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

Встроенное кэширование actions/setup-node:

Автоматически кэширует npm, yarn или pnpm
Определяет менеджер по lock-файлу
Использует правильный путь к кэшу

Вручную для полного контроля:

steps:
  - uses: actions/checkout@v4

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

  - name: Install dependencies
    run: npm ci

#Кэширование pip (Python)

name: Python CI with cache

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'
          cache: 'pip'  # Встроенное кэширование

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run tests
        run: pytest

Вручную для pip:

steps:
  - uses: actions/cache@v4
    with:
      path: |
        ~/.cache/pip
        ~/.local/share/pip
      key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
      restore-keys: |
        ${{ runner.os }}-pip-

#Кэширование Maven (Java)

name: Java CI with Maven

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Java
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: 'maven'

      - name: Build with Maven
        run: mvn -B package

      - name: Run tests
        run: mvn test

Путь к кэшу Maven: ~/.m2/repository

#Кэширование Gradle

steps:
  - uses: actions/cache@v4
    with:
      path: |
        ~/.gradle/caches
        ~/.gradle/wrapper
      key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
      restore-keys: |
        ${{ runner.os }}-gradle-

#Кэширование в GitLab CI

В GitLab CI кэширование настроено иначе — через ключевое слово cache:

# .gitlab-ci.yml
test:
  stage: test
  image: node:20
  cache:
    key: $CI_COMMIT_REF_SLUG
    paths:
      - node_modules/
    policy: pull-push
  script:
    - npm ci
    - npm test

Параметры cache:

key — идентификатор кэша (переменные CI/CD доступны)
paths — файлы для кэширования
policy — pull-push (по умолчанию), pull, или push

#Ключи кэша в GitLab CI

Доступные переменные:

Переменная	Описание
`$CI_COMMIT_REF_SLUG`	URL-safe имя ветки
`$CI_COMMIT_REF_NAME`	Имя ветки или тега
`$CI_PIPELINE_ID`	ID пайплайна
`$CI_PROJECT_ID`	ID проекта

Примеры ключей:

# Отдельный кэш для каждой ветки
cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - node_modules/

# Глобальный кэш для всех веток
cache:
  key: global-npm-cache
  paths:
    - node_modules/

# Кэш для конкретной версии зависимостей
cache:
  key: npm-$CI_COMMIT_REF_SLUG-${{ hashFiles('package-lock.json') }}
  paths:
    - node_modules/

#Политики кэширования

pull-push (по умолчанию):

cache:
  policy: pull-push  # Загрузить перед job, сохранить после

pull — только загрузка:

cache:
  policy: pull  # Только загрузить, не сохранять

push — только сохранение:

cache:
  policy: push  # Только сохранить, не загружать

#Кэширование Docker-слоёв

Не используйте actions/cache для Docker! Вместо этого:

Через buildx cache:

steps:
  - uses: docker/setup-buildx-action@v3

  - name: Build and push
    uses: docker/build-push-action@v5
    with:
      push: true
      tags: myapp:latest
      cache-from: type=gha
      cache-to: type=gha,mode=max

Через registry cache:

steps:
  - name: Build and push
    uses: docker/build-push-action@v5
    with:
      push: true
      tags: myapp:latest
      cache-from: type=registry,ref=myorg/myapp:buildcache
      cache-to: type=registry,ref=myorg/myapp:buildcache,mode=max

#Ограничения и лимиты

GitHub Actions:

Максимальный размер кэша: 10 ГБ на репозиторий
Лимит на отдельный кэш: нет, но в пределах 10 ГБ
Срок жизни кэша: 7 дней без использования
Удаление: LRU (Least Recently Used) при превышении лимита

GitLab CI:

Максимальный размер кэша: 10 ГБ на проект (настраивается администратором)
Кэш общий для всех job с одинаковым ключом
Срок жизни: пока не будет превышен лимит

#Когда кэш НЕ нужен

Не кэшируйте:

Маленькие зависимости (< 10 МБ) — установка быстрее кэша
Часто меняющиеся зависимости — кэш будет инвалидироваться
Docker-образы — используйте buildx cache
Артефакты сборки — используйте actions/upload-artifact

Пример:

# Не нужно кэшировать — установка быстрая
steps:
  - run: pip install requests  # 5 секунд

# Нужно кэшировать — установка долгая
steps:
  - run: pip install -r requirements.txt  # 2–3 минуты с tensorflow, pandas

#Отладка кэширования

Включите логирование:

steps:
  - uses: actions/cache@v4
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    id: cache-npm

  - name: Check cache
    run: |
      echo "Cache hit: ${{ steps.cache-npm.outputs.cache-hit }}"

Вывод:

cache-hit: true — кэш найден по точному ключу
cache-hit: false — кэш не найден или восстановлен по restore-keys

#Лучшие практики

Используйте встроенное кэширование (cache: 'npm', cache: 'pip') когда возможно
Кэшируйте по lock-файлам, а не по версиям в коде
Включайте ОС в ключ для разделения кэшей
Используйте restore-keys для graceful degradation
Измеряйте эффект — большой кэш может замедлить пайплайн
Не кэшируйте node_modules целиком — лучше ~/.npm для npm install

Переменная

Описание

$CI_COMMIT_REF_SLUG

URL-safe имя ветки

$CI_COMMIT_REF_NAME

Имя ветки или тега

$CI_PIPELINE_ID

ID пайплайна

$CI_PROJECT_ID

ID проекта