Производительность пайплайна: кэш, параллелизм, fail-fast

Кэш: правильный ключ — это хэш lock-файла

Столкнулся с медленным пайплайном и не знаешь, с чего начать? Ответ почти всегда один: закэшируй детерминированное и поставь быстрые проверки первыми. Вот как устроена каждая из этих частей.

Каждая CI-джоба стартует на чистом раннере, поэтому без кэша она переделывает каждый дорогой детерминированный шаг — прежде всего установку зависимостей — с нуля на каждом запуске. Кэш это чинит, но только если правильный его ключ. Ключ — это строка; кэш попадает, когда эта точная строка уже существует, иначе промахивается, и в конце успешной джобы сохраняется новый кэш. Значит, ключ обязан меняться ровно тогда, когда должно меняться содержимое, и никогда иначе.

Для зависимостей вход, определяющий node_modules, — это lock-файл, поэтому хэшируй его через hashFiles. Добавь restore-keys как упорядоченный список префиксов: на промахе GitHub идёт по ним по порядку и восстанавливает самый свежий кэш, чей ключ начинается с префикса, — частичное попадание, так что npm ci доустанавливает только дельту, а не все 1200 пакетов по сети.

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

Стоит различать три слоя кэша, каждый ключуется так же: кэш зависимостей (~/.npm, ~/.cache/pip, кэш Go-модулей — часто автоматом через cache: npm у setup-node), кэш сборки (инкрементальный вывод компилятора, удалённый кэш Turborepo/Nx) и кэш слоёв Docker (type=gha с buildx). Антипаттерн, убивающий все три, один и тот же: волатильный ключ. Запеки в ключ таймстамп или ${{ github.run_id }} — и он уникален на каждом запуске, поэтому никогда не попадает: кэш молча сохраняется и не читается ни разу, а ты вечно платишь полное время установки, веря, что у тебя есть кэш.

Fail-fast: самое дешёвое и самое вероятное падение — первым

needs превращает плоский список джоб в DAG: джоба с needs: [lint] не стартует, пока lint не пройдёт успешно. Одно это ключевое слово даёт закрыть медленную дорогую работу за дешёвой — так что двухсекундный провал lint обрубает запуск ещё до того, как двадцатиминутный e2e-набор поднимет хоть один браузер. Правило порядка — самое дешёвое и самое вероятное падение первым: lint и typecheck бегут за секунды и ловят самые частые ошибки, поэтому они идут в начало DAG, а всё медленное висит на них через needs.

jobs:
  lint:                       # ~10 с — дешёвый гейт
    runs-on: ubuntu-latest
    steps: [{ uses: actions/checkout@v4 }, { run: npm run lint && npm run typecheck }]

  unit:
    needs: lint               # не стартует, если lint упал
    runs-on: ubuntu-latest
    steps: [{ uses: actions/checkout@v4 }, { run: npm test }]

  build:
    needs: lint               # параллельно с unit — обоим нужен только lint
    runs-on: ubuntu-latest
    steps: [{ uses: actions/checkout@v4 }, { run: npm run build }]

  e2e:
    needs: [unit, build]      # медленный набор закрыт за всем дешёвым
    strategy:
      fail-fast: true         # один шард упал → отмена остальных
      matrix:
        browser: [chromium, firefox, webkit]
    runs-on: ubuntu-latest
    steps: [{ uses: actions/checkout@v4 }, { run: npx playwright test --project=${{ matrix.browser }} }]

Параллелизм и matrix: дроби работу, но fan-out не бесплатен

Когда джобы независимы — unit и build выше обоим нужен только lint — они бегут параллельно автоматически, срезая wall-clock. matrix — компактный способ размножить одну джобу по списку (браузеры, версии Node, ОС), порождая по джобе на ячейку. Подвох — стоимость. GitHub считает минуты каждой джобы независимо и округляет каждую вверх до целой минуты, так что матрица 3 браузера × 2 ОС — это шесть отдельных джоб, каждая платит свой checkout, установку и восстановление кэша. Параллелизм меняет оплачиваемые минуты на латентность: пять шардов по минуте финишируют за минуту wall-clock, но в счёте — пять минут. Распараллеливай там, где выигрыш по латентности реален; ограничивай разрастание fan-out через max-parallel.

Стоимость: минуты, размер раннера и простой

Прежде чем брать раннер побольше или раздувать матрицу, спроси себя: эта джоба реально ускорится, или дополнительные ядра просто будут простаивать и увеличивать счёт?

Раннер-минуты — это счёт. Linux — дешёвая база; Windows стоит примерно 2× за минуту, а macOS примерно 10×, так что неосторожная macOS-матрица — кратчайший путь к сюрпризу в инвойсе. Ещё два рычага режут в обе стороны. Раннер побольше (больше vCPU) заканчивает CPU-bound джобу быстрее, но стоит пропорционально дороже за минуту — окупается, только если джоба реально параллелится по ядрам; 16-ядерный раннер на однопоточной сборке просто платит 8× ни за что и простаивает. И время восстановления кэша не бесплатно: вытянуть кэш в несколько сотен МБ по сети может стоить дороже, чем пересборка, которую он экономит, — поэтому кэшируй медленно-производимое (зависимости, скомпилированный вывод), а не всё подряд.