Использование Hudson для сборки RPM-пакетов

Question

У меня есть проект C, созданный в Хадсоне для ночных сборок, у меня также есть файл спецификации .rpm, используемый для создания rpms из этих источников.

Есть ли у кого-нибудь опыт по созданию rpms из всего этого с помощью Hudson?

Прямо сейчас единственное решение, которое я вижу, - это создать задание, запускающее скрипт, который проверяет svn, экспортирует исходники, создает tarball и выполняет полную сборку rpm. Кажется, это плохо интегрируется с Хадсоном, например как мне собрать артефакты?

Answer 1

Я согласен с вышеизложенным - если вы можете создать RPM из любого каталога, вы можете написать скрипт процесса сборки и поместить его прямо в Hudson.

Вот магия:

rpmbuild --define '_topdir '`pwd` -ba SPECS/helloworld.spec 

Устанавливает каталог верхнего уровня для процесса сборки в качестве текущего каталога.

У меня была та же проблема, и я задокументировал весь процесс на
http://www.itforeveryone.co.uk/rpm-build-hudson-jenkins.html

Answer 2

Я сделал это для двух проектов сейчас. Это не сложно, но сильно зависит от вашего рабочего процесса. Самый важный вопрос: что вы хотите сделать с этим пакетом после его сборки? В моем предыдущем проекте пакет просто попал в хранилище, так что мне не нужно было собирать какие-либо артефакты.

В любом случае, пара подсказок от меня:

1. Вам понадобится область сборки для Hudson / Jenkins, это может быть просто каталог в JENKINS_HOME. Вам необходимо указать rpmbuild через .rpmmacros. Моя выглядит так же, как %_topdir /srv/build, но вы, конечно, можете определять здесь больше макросов.
2. В моем последнем проекте мне нужно было создавать RPM либо из ветвей интеграции (во временных рамках интеграции), либо из внешних линий (вне временных рамок интеграции). Для этого я создал скрипт на Perl, который проверял правильную ветку в зависимости от текущей даты и запускал rpmbuild -bb project.spec на ней. Так как этот скрипт также загружал RPM в репозиторий, мне больше ничего не нужно было, кроме этого единственного скрипта, то есть я фактически использовал Hudson как продвинутый менеджер cron (автоматическая сборка три раза в день, ручная сборка по щелчку мыши). Он все еще был запущен SVN, поэтому мы не создавали без необходимости.

3. Я хотел иметь чистые пакеты, а также сохранить возможность сборки из командной строки. По этой причине моя спецификация RPM автоматически создала свой собственный tarball из экспорта SVN. Я удалил функциональность экспорта для текущего проекта, так что теперь это выглядит так:

   %define module my_project
   %define _curdir .
   %define _release %(/usr/bin/svnversion -c %_curdir | %__sed 's/.*://g')
   %define _moddir %module-%_version-%_release
   %define _source %(/bin/tar czf %_sourcedir/%_moddir.tar.gz --transform="s|^./|%_moddir/|g" --exclude=.svn .; /bin/echo %_moddir.tar.gz)
   

   и позже в спецификации:

   Source0: %_source
   

4. В моем текущем проекте я разбил этот сценарий на части, так что мое текущее задание Jenkins состоит только из команды rpmbuild .... Причина в том, что мне не нужно было строить из разных веток.

В заключение: создание RPM возможно с помощью Jenkins, это довольно просто, поскольку сложная часть заключается в создании чистой спецификации RPM. Все остальное зависит от ваших потребностей, которые можно исправить с помощью небольшого количества сценариев или с помощью плагина Jenkins.

Answer 3

Не уверен, получил ли я очень хороший ответ на ваш вопрос.

Это сработало для меня, но вы чувствуете лишний вес для ваших нужд.

Я добился приличного успеха при использовании плагина maven rpm http://mojo.codehaus.org/rpm-maven-plugin/ в основном DSL для создания spec-файлов, размещения источников и т. д.

Верх - это артефакт maven, который Гудзону легче отследить.

Я добавил небольшой скрипт Groovy в сборку maven (http://docs.codehaus.org/display/GMAVEN/Executing+Groovy+Code) для моих нужд в конце, чтобы автоматически обновлять репозиторий yum, на котором размещаются сборки, но в вашей ситуации я бы, вероятно, использовал скрипт перед использованием плагина rpm для вызова make.

Честно говоря, я считаю, что вышеупомянутое решение немного весомо, в основном из-за многословности выполнения сценариев в maven, но оно работает, и для нас, с кучей разработчиков java, которые знают maven, работает хорошо.

Answer 4

В какой-то момент я заменил maven dsl, о котором я упоминал выше, на собственный плагин Scala, отчасти просто для изучения scala. Это действительно удовлетворяло еще несколько потребностей. Но сейчас я бы просто рекомендовал использовать

fpm, который отлично справляется с 90% потребностей создания rpm (также делает deb, et. Al)

http://www.semicomplete.com/blog/geekery/fpm.html

проект здесь: https://github.com/jordansissel/fpm

Answer 5

Ant можно использовать для создания RPM с помощью встроенной задачи RPM. Вы можете компилировать исходники C с помощью Ant с помощью задачи CC (из Ant-contrib).

Затем вы можете использовать Hudson для сборки и упаковки нашего программного обеспечения.

Answer 6

Что вы используете в качестве инструмента сборки на Hudson? Сделайте

Вы можете создать структуру каталогов, которую rpm build будет использовать в рабочей области задания Hudson - это уже может быть в проверке, которую делает Hudson, или она может быть создана отдельно вашим скриптом сборки. Из этого каталога вы можете создавать свои rpms (используя внешний процесс, который вы запускаете из Hudson?). После этого вы можете скопировать полученный rpm в каталог артефактов, используя обычные настройки Hudson configure. (Хадсон определяет количество переменных окружения , которые вы можете использовать - одним из них является местоположение рабочей области)

Answer 7

Я сам этого не сделал, но подумал бы, что вы могли бы заставить Хадсона собрать rpms, но с областью сборки rpm, находящейся в рабочем пространстве Hudson. Тогда вы сможете ссылаться на RPM как артефакты.

Здесь - это то, как вы используете другую область сборки с оборотами в минуту.

Answer 8

после некоторого исследования информации из многих постов блога и других ресурсов я объединил все это в один скрипт, который можно легко использовать в jenkins для сборки пакетов: https://github.com/jhrcz/jenkins-rpm-builder.

он собирает артефакты (пакеты rpm) в виде репозитория yum, поэтому при некоторой конфигурации httpd может быть направлен на последнее стабильное хранилище сборки.

в коде вы можете обнаружить, что он поддерживает подписывание пакетов и пытается разрешить все различия, необходимые между el5 и el6.

Answer 9

Вот сценарий оболочки Jenkins, который мы используем:

export PROJECT_NAME=
export PROJECT_VERSION=

#Cleanup
rm -f /tmp/JENKINS-BUILD/SPECS/$PROJECT_NAME.rpm.spec 
rm -Rf /tmp/JENKINS-BUILD/SOURCES/$PROJECT_NAME /usr/src/redhat/SOURCES/$PROJECT_NAME

#Copy sources/artifacts
cp /var/lib/jenkins/jobs/$PROJECT_NAME/workspace/project-set/$PROJECT_NAME/showme/include/$PROJECT_NAME.rpm.spec /tmp/JENKINS-BUILD/SPECS/$PROJECT_NAME.rpm.spec
cp -R /var/lib/jenkins/jobs/$PROJECT_NAME/workspace/project-set/$PROJECT_NAME/showme /usr/src/redhat/SOURCES/$PROJECT_NAME
cp -R /var/lib/jenkins/jobs/$PROJECT_NAME/workspace/project-set/$PROJECT_NAME/showme /tmp/JENKINS-BUILD/SOURCES/$PROJECT_NAME

#Build RPM
rpmbuild --define 'BUILD_NUMBER '$BUILD_NUMBER -ba /tmp/JENKINS-BUILD/SPECS/$PROJECT_NAME.rpm.spec --define '_topdir '/tmp/JENKINS-BUILD/

cp /tmp/JENKINS-BUILD/RPMS/noarch/$PROJECT_NAME-$PROJECT_VERSION-$BUILD_NUMBER.noarch.rpm /var/lib/jenkins/jobs/$PROJECT_NAME/workspace

(Кредит JT / JWT)