Sử dụng Hudson để xây dựng gói RPM

Question

Tôi đã thiết lập dự án C ở Hudson khi xây dựng, tôi cũng có tệp .rpm spec được sử dụng để tạo rpms từ các nguồn này.

Có ai có bất kỳ kinh nghiệm nào về cách xây dựng RPM trong tất cả điều này bằng cách sử dụng Hudson không?

Ngay bây giờ giải pháp duy nhất tôi thấy là thiết lập công việc chạy tập lệnh kiểm tra svn xuất các nguồn, tạo tarball và thực hiện toàn bộ vòng/phút. Điều này dường như không hòa hợp tốt với Hudson - ví dụ: làm cách nào để thu thập các đồ tạo tác?

Answer 1

Tôi chưa tự mình làm nhưng nghĩ rằng bạn có thể có Hudson xây dựng các rpms nhưng với khu vực xây dựng rpm nằm trong vùng làm việc Hudson. Sau đó, bạn sẽ có thể liên kết đến các rpms như hiện vật.

Here là cách bạn sử dụng một khu vực xây dựng khác với rpm.

Answer 2

Bạn đang sử dụng công cụ xây dựng nào trên hudson? Chế tạo?

Bạn có thể tạo cấu trúc thư mục mà công cụ xây dựng rpm sẽ sử dụng trong Không gian làm việc của Công việc Hudson - điều này đã có trong thanh toán mà Hudson thực hiện hoặc có thể được tạo riêng bằng tập lệnh xây dựng của bạn. Từ thư mục này, bạn có thể tạo rpms của bạn (sử dụng một quá trình bên ngoài mà bạn khởi động từ Hudson?). Sau đó bạn có thể sao chép rpm kết quả vào thư mục tạo tác bằng cách sử dụng thiết lập cấu hình Hudson bình thường. (Hudson xác định số lượng environment variables mà bạn có thể sử dụng - vị trí không gian làm việc là một trong số đó)

Answer 3

Không chắc chắn nếu tôi có câu trả lời hay cho câu hỏi của bạn.

Điều này đã hiệu quả đối với tôi, nhưng cảm thấy thừa cân cho nhu cầu của bạn.

Tôi đã có một số tiền khá thành công với điều này bằng cách sử dụng các plugin maven rpm http://mojo.codehaus.org/rpm-maven-plugin/ cơ bản là một DSL để tạo file spec, đặt ra các nguồn vv

Ngược ở đây là một tạo tác maven rằng hudson có thể dễ dàng theo dõi hơn.

Tôi đã thêm một kịch bản nhỏ trong xây dựng maven (http://docs.codehaus.org/display/GMAVEN/Executing+Groovy+Code) cho nhu cầu của mình ở cuối để tự động cập nhật kho lưu trữ yum, nhưng trong trường hợp của bạn, tôi có thể sử dụng tập lệnh trước rpm plugin được sử dụng để gọi thực hiện.

Thành thật mà nói, tôi cảm thấy giải pháp trên hơi nặng, chủ yếu là do việc viết kịch bản trong maven, nhưng nó hoạt động, và đối với chúng tôi, với một nhóm các nhà phát triển java biết maven, hoạt động tốt.

Answer 4

Ant có thể được sử dụng để tạo RPM thông qua tác vụ RPM được tích hợp sẵn. Bạn có thể biên dịch các nguồn C bằng Ant với nhiệm vụ CC (từ Ant-contrib).

Sau đó, bạn có thể sử dụng Hudson để xây dựng và đóng gói phần mềm của chúng tôi.

Answer 5

Tôi đã thực hiện nó cho hai dự án ngay bây giờ. Nó không khó, nhưng phụ thuộc rất nhiều vào công việc của bạn. Câu hỏi quan trọng nhất là: bạn muốn làm gì với gói đó sau khi nó được xây dựng? Trong dự án trước đây của tôi, gói phần mềm đã đi đến kho lưu trữ, vì vậy mà tôi không cần phải thu thập bất kỳ đồ tạo tác nào.

Dù bằng cách nào, một vài gợi ý từ tôi:

1. Bạn sẽ cần một diện tích xây dựng cho Hudson/Jenkins, nó có thể chỉ là một thư mục trong JENKINS_HOME. Bạn cần trỏ rpmbuild đến nó qua .rpmmacros. Của tôi trông giống như %_topdir /srv/build, nhưng tất nhiên bạn hoàn toàn miễn phí để xác định nhiều macro hơn.
2. Trong dự án cuối cùng của mình, tôi cần xây dựng RPM từ các nhánh tích hợp (trong khung thời gian tích hợp) hoặc từ thân cây (bên ngoài khung thời gian tích hợp). Đối với điều đó, tôi đã xây dựng một kịch bản Perl, mà kiểm tra các chi nhánh chính xác tùy thuộc vào ngày hiện tại và chạy rpmbuild -bb project.spec trên đó. Vì kịch bản này cũng đã tải lên RPM cho kho, tôi không cần gì khác ngoài kịch bản đơn này, có nghĩa là tôi đã sử dụng Hudson như một trình quản lý cron tiên tiến (tự động xây dựng ba lần một ngày, xây dựng bằng tay khi nhấp chuột). Nó vẫn còn được kích hoạt SVN, để chúng tôi không xây dựng một cách không cần thiết.

3. Tôi muốn có gói sạch và cũng có thể duy trì khả năng xây dựng từ dòng lệnh. Vì lý do đó, thông số RPM của tôi đã tự động tạo tarball của riêng nó từ một xuất SVN. Tôi đã đưa ra những chức năng xuất khẩu ra cho dự án hiện tại, vì vậy nó trông như thế này bây giờ:

   %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) 
   

   và sau này trong spec:

   Source0: %_source 
   

4. Trong dự án hiện tại của tôi, tôi đã chia mà tập lệnh thành từng phần, do đó công việc Jenkins hiện tại của tôi chỉ bao gồm lệnh rpmbuild .... Lý do là tôi không cần phải xây dựng từ các nhánh khác nhau.

Kết luận: việc tạo RPM có thể thực hiện được thông qua Jenkins, điều này khá dễ dàng, vì phần khó làm cho thông số RPM sạch. Tất cả mọi thứ khác phụ thuộc vào nhu cầu của bạn, có thể khắc phục được với một chút kịch bản hoặc với plugin Jenkins.

Answer 6

Tôi đồng ý với những điều trên - khi bạn có thể tạo RPM từ bất kỳ thư mục nào, bạn có thể tạo kịch bản cho quá trình xây dựng và đưa nó thẳng vào Hudson.

Đây là sự kỳ diệu:

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

này đặt thư mục cấp cao nhất cho quá trình xây dựng như thư mục hiện hành.

tôi đã cùng một vấn đề và ghi nhận quá trình đầy đủ tại
http://www.itforeveryone.co.uk/rpm-build-hudson-jenkins.html

Answer 7

Tại một thời điểm, tôi thay thế dsl maven tôi đã đề cập ở trên với một tùy chỉnh Scala plugin, trong phần chỉ để học scala. Nó đã đáp ứng một số nhu cầu nhiều hơn thế. Nhưng bây giờ, tôi chỉ ủng hộ việc sử dụng

fpm, một công việc tuyệt vời trong 90% nhu cầu tạo rpm (cũng như deb, et.al)

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

dự án ở đây: https://github.com/jordansissel/fpm

Answer 8

Dưới đây là một kịch bản shell Jenkins chúng tôi sử dụng:

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 

(Credit để JT/JWT)

Answer 9

sau khi một số nghiên cứu của thông tin từ nhiều bài đăng trên blog và các tài nguyên khác tôi đã hợp nhất tất cả thành một tập lệnh, có thể dễ dàng sử dụng tôi n jenkins để đóng gói: https://github.com/jhrcz/jenkins-rpm-builder.

nó thu thập các tạo phẩm (gói rpm) trong biểu mẫu của kho yum, do đó, với một số cấu hình, httpd có thể được chuyển đến repo xây dựng ổn định mới nhất.

trong mã bạn có thể thấy rằng nó hỗ trợ ký gói và cố gắng giải quyết tất cả các khác biệt cần thiết betwen el5 và el6.