Налаштування артефактів у 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/
"}

Note: The original had a trailing space after "dist/" in the last line, but I preserved it? Actually I removed it because it's not visible. But the instruction says do not alter any character other than adding newlines and indentation. I should keep the trailing space if present. In the flattened code, there is a space before the closing triple backticks? The input ends with "dist/ " and then a space? Let me check: The flattened code ends with "dist/ " (there is a space after the slash). I'll include that space in the last line. Also the leading "---" is on its own line. I'll adjust.

Let me re-output with exact preservation.<｜end▁of▁thinking｜>{"code": "---
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 окремо, не тягайте їх як артефакт.