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

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

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

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

Ответ 1

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

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

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

Потенциал - это артефакт maven, который hudson может легко отслеживать.

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

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

Ответ 2

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

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

Вам понадобится область сборки для Hudson/Jenkins, это может быть просто каталог в JENKINS_HOME. Вам нужно указать rpmbuild с помощью .rpmmacros. Mine выглядит так же, как %_topdir /srv/build, но вы, конечно, можете определить там больше макросов.
В моем последнем проекте мне нужно было создать RPM либо из ветвей интеграции (во временном интервале интеграции), либо из магистрали (за пределами временного интервала интеграции). Для этого я построил Perl script, который проверил правильную ветку в зависимости от текущей даты и запустил rpmbuild -bb project.spec на ней. Поскольку этот script также загрузил RPM в репозиторий, мне не нужно было ничего кроме этого сингла script, то есть я фактически использовал Hudson как продвинутый менеджер cron (автоматическая сборка три раза в день, ручная сборка по щелчку мыши). Тем не менее, это было SVN-инициировано, так что мы не строили излишне.
Я хотел иметь чистые пакеты, а также сохранить возможность строить из командной строки. По этой причине моя спецификация 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
```
В моем текущем проекте я разделил script на части, так что мое текущее задание Дженкинса состоит только из команды rpmbuild .... Причина в том, что мне не нужно было строить из разных ветвей.

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

Ответ 3

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

Здесь волшебство:

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

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

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

Ответ 4

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

Here заключается в том, как вы используете другую область сборки с rpm.

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

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

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

Ответ 8

Здесь оболочка Jenkins script мы используем:

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)

Ответ 9

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

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

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