Перейти на PRO

Что такое артефакты (artifacts) в GitLab CI/CD?

Тип вопроса: DevOps Вероятность: 26% Категория: Data Scientist / ML Инженер

Ответ

В GitLab CI/CD артефакты — это набор файлов или директорий, которые создаются в процессе выполнения job (задачи) в пайплайне и сохраняются для последующего использования. Они не являются часть исходного кода репозитория.

Типичные примеры артефактов:

  • Скомпилированные бинарные файлы или пакеты (.jar, .exe, .deb).
  • Результаты выполнения тестов (логи, отчеты в JUnit XML, Allure, Cobertura форматах).
  • Документация, сгенерированная из кода.
  • Файлы конфигурации для деплоя.

Ключевые возможности и синтаксис:

Артефакты определяются в .gitlab-ci.yml с помощью ключа artifacts.

build_job:
  stage: build
  script:
    - mvn clean package  # Сборка Java-проекта
  artifacts:
    paths:
      - target/*.jar     # Сохраняем все JAR-файлы из target/
    expire_in: 1 week    # Артефакты удалятся через неделю

test_job:
  stage: test
  script:
    - mvn test
    - pytest --junitxml=report.xml  # Запуск Python-тестов
  artifacts:
    paths:
      - target/surefire-reports/  # Отчеты Maven Surefire
      - report.xml                # Отчет pytest
    reports:
      junit: report.xml  # Специальный отчет для GitLab, отображается в UI
    when: always         # Сохранять артефакты даже если job упал

deploy_job:
  stage: deploy
  script:
    - scp target/*.jar user@server:/app/  # Копируем артефакт с билд-джобы
  dependencies:
    - build_job  # Указываем, что этой джобе нужны артефакты от build_job

Важные аспекты:

  • Хранение: Артефакты хранятся на GitLab-сервере и доступны для скачивания через веб-интерфейс (вкладка "Job") или API. По умолчанию хранятся 30 дней (expire_in).
  • Передача между джобами: Джобы в последующих стадиях (stages) могут использовать артефакты из предыдущих джоб, если указать их в dependencies. Без этого каждая джоба начинается с чистого состояния.
  • Отчеты (reports): Специальные ключи, такие как reports:junit, позволяют GitLab парсить результаты тестов и отображать статистику, графики с историей падений и т.д. в Merge Request.
  • Кэширование vs Артефакты: Кэш (cache) используется для ускорения повторных сборок (например, зависимости node_modules/), а артефакты — для передачи результатов работы пайплайна.

Ответ 18+ 🔞

Слушай, давай разжую про артефакты в GitLab CI, а то у некоторых товарищей в голове каша, будто они впервые про пайплайны услышали. Представь, что твой пайплайн — это конвейер на заводе. На каждом этапе что-то делается: деталь точат, красят, собирают. Так вот, артефакты — это как раз эти готовые детали, которые с конвейера снимают и кладут на склад, чтобы на следующем этапе их можно было взять и прикрутить куда надо. Это НЕ исходники из гита, это то, что твои джобы наваяли в процессе.

Что обычно в эти артефакты пихают, ёпта?

  • Собранные штуки: всякие .jar, .exe, пакеты .deb — то, что потом на сервак заливать.
  • Отчёты от тестов: логи, XML-ки для JUnit, результаты покрытия кода. Чтобы потом не гадать, а почему всё упало, а просто посмотреть.
  • Документацию, которую из кода нагенерировали.
  • Конфиги для деплоя. Короче, любой файл, который нужен позже.

Как этим хозяйством рулить в .gitlab-ci.yml?

Всё через ключ artifacts делается. Смотри, примерчик:

build_job:
  stage: build
  script:
    - mvn clean package  # Классика, собираем Java-проект
  artifacts:
    paths:
      - target/*.jar     # Вот так говорим: "Сохрани-ка, дружок, все jar-ники из папки target"
    expire_in: 1 week    # А это чтоб хлам не копился. Через неделю самоудалится — красота.

test_job:
  stage: test
  script:
    - mvn test
    - pytest --junitxml=report.xml  # Запускаем тесты на Python
  artifacts:
    paths:
      - target/surefire-reports/  # Отчёты от Maven
      - report.xml                # И от pytest
    reports:
      junit: report.xml  # А это магия! GitLab сам распарсит отчёт и красивые графики в интерфейсе нарисует.
    when: always         # Сохраняй артефакты ВСЕГДА, даже если джоба обосралась и тесты не прошли. Для расследования.

deploy_job:
  stage: deploy
  script:
    - scp target/*.jar user@server:/app/  # Тут уже артефакт с билд-джобы на сервер тащим
  dependencies:
    - build_job  # Ключевой момент! Говорим: "Эй, дай мне файлы, которые `build_job` оставила". Без этого — нихуя не получишь, будешь в пустой папке сидеть.

Важные моменты, чтобы не облажаться:

  • Где лежат? На сервере GitLab, блядь. Скачать можно прямо из интерфейса в логе джобы или через API. По дефолту 30 дней валяются, но expire_in — твой друг, не забывай про него, а то диск забьётся, доверия ебать ноль к тем, кто мусор не убирает.
  • Передача по цепочке: Если джоба deploy хочет взять jar-ник от build, она должна явно указать это в dependencies. Иначе каждая джоба стартует с чистого листа, как будто ничего и не было. Сам от себя охуеешь, когда поймёшь, что забыл эту строчку.
  • Отчёты (reports): Это не просто файлы. Специальные типы вроде junit или cobertura GitLab умеет читать и показывать тебе прямо в Merge Request — сколько тестов упало, какое покрытие. Очень удобно, удивление пиздец, когда впервые видишь.
  • Не путай с кэшем! Это, блядь, частая ошибка новичков. Кэш (cache) — это для ускорения, чтоб каждый раз зависимости (типа node_modules/) заново не качать. А артефакты — это РЕЗУЛЬТАТ работы, который нужно передать дальше. Перепутаешь — будет тебе хитрая жопа с непонятными багами.
© ХакСобесов, 2026
support@hacksobesov.com