Оптимизация установки зависимостей PHP с Composer в GitLab CI

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

Проблемы при частых установках

Каждый раз, когда выполняется команда composer install, Composer скачивает пакеты нужных версий с GitHub. Это может вызвать:

• Ошибки сетевого соединения с GitHub.
• Ограничения на количество запросов (rate limit), если с сервера уже выполнялось много запросов в течение дня.
• Проблемы с сетью или интернет-соединением на сервере.

  Особенно это критично, когда необходимо собрать ветку для master или исправить баг, а установка зависимостей не удаётся из-за вышеперечисленных проблем.

Решение: локальный кэш пакетов

Чтобы минимизировать эти проблемы, рекомендуется кэшировать пакеты, скачиваемые с GitHub, в локальном кэше GitLab (или S3).

Принцип работы:

• Если пакет, например laravel/laravel-2.3.2.zip, уже существует в кэше, Composer использует его, а не скачивает заново.
• Это снижает нагрузку на сеть и позволяет избежать лимитов на GitHub.

Настройка .gitlab-ci.yml для кэширования

Пример конфигурации CI для установки PHP-зависимостей с использованием кэша:

stages:
  - prepare

php-dependencies:
  stage: prepare
  image: composer:latest
  script:
    # Настройка кэша Composer
    - composer config -g cache-dir .composer-cache
    - composer install --prefer-dist --no-ansi --no-interaction --no-progress --ignore-platform-reqs
  cache:
    key:
      files:
        - composer.lock
    paths:
      - .composer-cache
  artifacts:
    expire_in: 30 mins
    paths:
      - vendor/

Как работает кэш GitLab

1. Кэш по ключу composer.lock GitLab проверяет ключ кэша на основе файла composer.lock.

   • Если файл изменился, кэш сбрасывается, и Composer скачивает новые версии пакетов.
   • Это полезно, когда разработчик обновил зависимость и закоммитил изменения в composer.lock.

2. Разница между кэшем и артефактами

   • Кэш хранится только на конкретном runner, где он был создан. Если следующий шаг сборки выполняется на другом runner, кэш может быть недоступен.
   • Артефакты позволяют передавать директорию vendor/ между шагами сборки, чтобы сборка контейнера могла использовать готовые зависимости.
   • При этом мы не держим весь vendor/ в кэше, так как он может занимать сотни мегабайт в несжатом виде.