GitLab CI предоставляет удобную возможность сохранения артефактов сборок в GitLab. Артефакт - любой файл, который разработчик хочет сохранить на продолжительное время после сборки. Данная возможность может использоваться для хранения дистрибутивов и различных журналов сборок. Использовать артефакты очень просто. В статье разберем как это реализовано на примере публикации собранного DEB пакета, который позже возможно скачать из GitLab.
Артефакты GitLab CI не всегда являются самым удобным средством, иногда вам может потребоваться подключить FTP, SFTP, публикацию в Nexus или другие системы хранения артефактов, однако, часто достаточно просто иметь хранилище, которое позволит просто получить доступ к результату сборки.
Рассмотрим использование функции на примере простого сборочного сценария gitlab-ci.yml, представленного ниже:
image: python:2.7
variables:
PACKAGE: private-package
stages:
- build
before_script:
- pip install --user -r requirements.txt
build:
stage: build
script:
- export PATH=$PATH:/root/.local/bin
- export PACKAGE_VERSION=$(cat version)
- export BUILDTIME=$(date +"%s")
- make
- cp -R deb/* $PACKAGE
- "echo \"Package: $PACKAGE\" >> $PACKAGE/DEBIAN/control"
- "echo \"Version: $PACKAGE_VERSION\" >> $PACKAGE/DEBIAN/control"
- "echo >> $PACKAGE/DEBIAN/control"
- dpkg-deb --build $PACKAGE
- mkdir -p releases
- mv $PACKAGE.deb releases/$PACKAGE-$PACKAGE_VERSION-$BUILDTIME-all.deb
artifacts:
paths:
- releases/*.deb
expire_in: 1 month
В данном сценарии происходит сборка проекта на Python с использованием упаковщика Pyinstaller. Вся работа происходит в Makefile, который здесь опущен.
Основные задачи по созданию DEB-пакета хорошо описаны в документации. Разберем несколько моментов подробнее:
В корне будущего пакета должен находиться каталог DEBIAN с файлом control следующего содержания внутри:
Maintainer: BWSoft Management, LLC
Architecture: all
Description: Private Package
Package: private-package
Version: 0.1
В нашем сборочном скрипте последние две строчки файла control формируются динамически следующим кодом:
- export PACKAGE_VERSION=$(cat version)
- "echo \"Package: $PACKAGE\" >> $PACKAGE/DEBIAN/control"
- "echo \"Version: $PACKAGE_VERSION\" >> $PACKAGE/DEBIAN/control"
- "echo >> $PACKAGE/DEBIAN/control"
Можно не доставать версию пакета из файла version, как сделано в примере, а использовать переменную для группы проектов GitLab, однако, в данном случае, мы считаем использованный подход более удобным. Сборщик DEB требует пустой строки в конце файла.
Далее собираем DEB-пакет стандартным способом, переименовываем его и кладем в корректный каталог, который будем использовать для поиска артефактов:
- dpkg-deb --build $PACKAGE
- mkdir -p releases
- mv $PACKAGE.deb releases/$PACKAGE-$PACKAGE_VERSION-$BUILDTIME-all.deb
Публикация артефакта выполняется с помощью секции artifacts:
artifacts:
paths:
- releases/*.deb
expire_in: 1 month
Здесь все просто, указываем пути к артефактам – в нашем случае все файлы в каталоге releases с расширением *.deb. Указываем, что артефакты необходимо хранить в течение месяца.
После успешной сборки проекта артефакты доступны через правый сайдбар задачи. Их можно скачать или просмотреть детально:
Заключение
В этом примере мы рассмотрели простой подход, который может использоваться для сохранения артефактов сборки на сервер GitLab. Этот подход не вполне удобен, если требуется предоставлять артефакты в автоматизированном режиме третим лицам, однако, если потребитель данных артефактов – авторизированный пользователь GitLab, подход успешно может применяться в коммерческой разработке. Впрочем, GitLab предоставляет API для доступа к артефактам сборки, это может использоваться для организации доступа третих лиц или экспорта артефактов во внешние хранилища.
Если вам понравился этот пост, поделитесь им с друзьями.