Настройка артефактов в CI/CD: GitLab и GitHub

Мы часто видим, как команды тратят часы на пересборку артефактов из-за неправильной настройки CI/CD. Вместо того чтобы передать скомпилированный бинарник между джобами, они заново проходят все шаги сборки. Результат — время пайплайна растёт, а разработчики ждут. Неправильная конфигурация артефактов — это лишние расходы на CI-минуты и время разработчиков. В этой статье разберём настройку артефактов в CI/CD для GitLab CI и GitHub Actions.

Недавно к нам обратилась команда микросервисов: их пайплайн занимал 45 минут из-за того, что каждый сервис собирался с нуля на каждом коммите. После настройки передачи артефактов время упало до 12 минут — сокращение на 73%, что сэкономило команде существенную часть бюджета на CI. Такая экономия возможна, если правильно настроить артефакты и исключить неявные пересборки.

Почему артефакты нельзя заменить кэшем?

Их часто путают. Кэш — для ускорения повторяющихся операций (зависимости, промежуточные файлы компиляции). Артефакт — для передачи результатов между джобами в рамках одного пайплайна.

• Кэш: живёт между запусками пайплайна, может быть устаревшим, попадание необязательно.
• Артефакт: создаётся в текущем пайплайне, передаётся в следующие джобы гарантированно, удаляется по expire_in.

Сравнение в таблице:

Как артефакты ускоряют пайплайн?

Правильная настройка артефактов позволяет строить DAG-пайплайны, где джобы не ждут завершения предыдущей стадии целиком, а стартуют сразу после получения необходимых артефактов. В результата время выполнения сокращается на 30–70%. Например, в одном из проектов мы заменили линейный пайплайн на DAG с передачей артефактов — пайплайн стал выполняться за 8 минут вместо 25. Средняя экономия составила $630–910 в месяц за счёт снижения затрат на CI-минуты.

Как настроить артефакты в GitLab CI?

build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
      - package.json
    expire_in: 1 hour
    when: always
test:
  stage: test
  needs:
    - job: build
      artifacts: true
  script:
    - npm run test
  artifacts:
    reports:
      junit: reports/junit.xml
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
deploy:
  stage: deploy
  needs:
    - job: build
      artifacts: true
  script:
    - rsync -av dist/ user@server:/var/www/app/

needs с artifacts: true — джоба deploy скачает артефакты из build без ожидания промежуточных стадий. Это DAG-пайплайн — более быстрая альтернатива линейным стадиям. Подробнее в документации GitLab CI.

Как передать артефакты в GitHub Actions?

---
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: frontend-dist-${{ github.sha }}
          path: dist/
          retention-days: 1
          if-no-files-found: error
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: frontend-dist-${{ github.sha }}
          path: dist/
      - run: ./scripts/deploy.sh dist/

if-no-files-found: error — важная настройка. По умолчанию upload успешно завершается даже если файлов нет, и следующая джоба скачает пустой артефакт. Лучше упасть явно. retention-days: 1 для промежуточных артефактов сборки — они нужны только в рамках этого пайплайна. Для релизных — длиннее. Подробнее в документации GitHub Actions.

Сравнение GitLab CI и GitHub Actions

Когда стоит использовать внешние хранилища?

Для артефактов, которые нужны за пределами одного пайплайна — релизные бинарники, Docker-образы, npm-пакеты — CI storage не подходит. Здесь нужны внешние хранилища:

• GitHub Releases / GitLab Releases — артефакты прикрепляются к тегу и доступны через API.
• S3 / GCS — для бинарников и статических файлов с версионированием.
• Nexus / Artifactory — для Maven, npm, Docker в корпоративной инфраструктуре.
• Docker Registry — образы тегируются git SHA и/или semver-тегом.

Публикация в Nexus из GitLab CI:

publish:
  stage: publish
  needs:
    - job: build
      artifacts: true
  script:
    - mvn deploy -s .mvn/settings.xml \
        -Dnexus.url=$NEXUS_URL \
        -Dnexus.username=$NEXUS_USER \
        -Dnexus.password=$NEXUS_PASS \
        -DskipTests
  rules:
    - if: '$CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+/'

Деплоить в Nexus только с тегов — правильная политика. Хранение артефактов во внешних хранилищах снижает затраты на CI-минуты, освобождая место в CI.

Пошаговый план настройки артефактов

1. Аудит текущих пайплайнов — выявить все места, где создаются и потребляются артефакты.
2. Определение необходимых артефактов — отделить промежуточные (dist/, reports/) от финальных (релизные бинарники).
3. Конфигурация artifacts/upload-artifact — задать правильные пути, сроки хранения и условия сохранения.
4. Интеграция с внешними хранилищами — подключить S3, Nexus или Docker Registry для долгосрочного хранения.
5. Тестирование и мониторинг — проверить, что артефакты передаются корректно, и настроить алерты на пустые артефакты.

Что входит в работу по настройке артефактов

Мы оцениваем текущий пайплайн, выявляем узкие места и настраиваем передачу артефактов под ключ. Результат:

• Аудит пайплайнов: какие артефакты создаются, как долго живут, где хранятся.
• Конфигурация artifacts / upload-artifact с оптимальными expire_in и retention-days.
• Интеграция с внешними хранилищами (S3, Nexus, Docker Registry) при необходимости.
• Документация по процессу и рекомендации по дальнейшей оптимизации.
• Поддержка в течение месяца после внедрения.

Мы помогли командам сократить время пайплайнов на 30–70% за счёт правильной настройки артефактов. Свяжитесь с нами для аудита вашего пайплайна — мы оценим текущую конфигурацию за один день и предложим оптимальное решение. Закажите настройку артефактов под ключ и начните экономить время и бюджет уже сегодня.

Типичные ошибки при настройке артефактов

• Слишком долгое хранение: expire_in: never забивает storage. Ставьте разумные лимиты.
• Отсутствие if-no-files-found: error в GitHub Actions — следующий шаг может молча задеплоить пустой артефакт.
• Передача зависимостей вместо результатов: кэшируйте node_modules отдельно, не таскайте их как артефакт.