2012-08-07 40 views
7

Tôi đang cố gắng di chuyển một kịch bản lệnh Ant mà tôi đã viết để xây dựng và triển khai các dự án từ bên trong khung công tác Jenkins (thay vì được kích hoạt từ móc hậu SVN, đó là cách chúng tôi bước đầu tiên tiếp cận mọi thứ). Mọi thứ đều tuyệt vời, ngoại trừ tôi cần các tệp stage cho bước triển khai và tôi muốn đưa chúng vào thư mục 'build' mà Jenkins tạo cho công việc (và kể từ build.xml của tôi sống ở một vị trí không thuộc dự án cụ thể, $ { basedir} và $ {user.dir} không trỏ đến vị trí mong muốn).Làm thế nào để xác định thư mục xây dựng Jenkins từ Ant?

trong cấu hình Jenkins, tôi đã thiết lập như sau:

[Jenkins] Build Ghi Root Directory: E:/xây dựng/$ {} ITEM_FULLNAME

[Job Cụ thể] Build file : C: \ vc-tools \ shadow \ build.xml

khi chạy bản dựng, tập lệnh được khởi chạy phù hợp và tạo thư mục dựng công việc cụ thể, ví dụ:

E: \ xây dựng \ Test \ 2012-08-07_12-51-21

Tôi muốn nhận được ở thư mục này từ bên trong xây dựng kịch bản, nhưng không thể tìm ra cách. một số trong những điều tôi đã cố gắng:

[echo] ${basedir}: C:\vc-tools\shadow 
[echo] ${user.dir}: C:\vc-tools 
[echo] ${env.workspace}: C:\Program Files (x86)\Jenkins\workspace\Test 
[echo] ${env.build_id}: 2012-08-07_12-51-21 
[echo] ${jenkins_home}: C:\Program Files (x86)\Jenkins 
[echo] ${BuildDir}: E:/builds/${ITEM_FULLNAME} 

lưu ý: cho rằng cuối cùng, tôi đã cố gắng đi qua trong:

BuildDir=E:/builds/${ITEM_FULLNAME} 

như một thuộc tính cấu hình từ công việc trong vòng Jenkins (rõ ràng mở rộng $ {} không diễn ra trong ngữ cảnh này).

theo documentation, không có biến môi trường cụ thể nào được đặt thành đường dẫn thư mục dựng đầy đủ - tôi có thể giả mạo bằng cách mã hóa phần tử E: \ builds root và tacking trên $ {env.build_id}, nhưng hy vọng sẽ có một cách dễ dàng hơn để truy cập đường dẫn đầy đủ từ thứ mà Jenkins phơi bày (hoặc thuộc tính Ant và biến môi trường) để làm cho kịch bản linh hoạt hơn.

Tôi đang sử dụng phiên bản Jenkins 1.476.

cảm ơn

+0

Có vẻ như bạn đang làm điều gì đó rất kỳ quặc, điều mà tôi hoàn toàn không hiểu. Tại sao tệp build.xml không nằm trong thư mục gốc của dự án bạn đang xây dựng? Thông thường bạn chỉ cần cấu hình Jenkins kéo các tệp dự án ra khỏi hệ thống SCM và sau đó chạy bản dựng ... Tất cả điều này xảy ra trong "không gian làm việc" mà Jenkins quản lý cho công việc xây dựng đó. –

+0

Tại sao bạn cần thư mục? Bạn có thể sử dụng đường dẫn tương đối an toàn –

+0

@ MarkO'Connor: - Tôi có một kịch bản xây dựng chung có thể được thừa hưởng cho một số dự án (có một tệp thuộc tính dự án cụ thể mà tập lệnh kéo xuống để đủ điều kiện làm việc của nó, nhưng tôi không t xem giá trị, tại thời điểm này, trong việc sao chép cùng một tệp build.xml trên nhiều, tương tự, các dự án). – rguilbault

Trả lời

11

Luôn luôn là ý tưởng hay khi dự án của bạn có bản sao logic xây dựng kèm theo mã nguồn. Nó làm cho việc xây dựng của bạn dễ dàng hơn trên các máy.

Có nói rằng cũng khá phổ biến khi thiết lập tệp xây dựng chứa logic xây dựng chung được chia sẻ. ANT xác định các nhiệm vụ sau để hỗ trợ hoạt động như:

Vì vậy, một giải pháp khả thi là để lưu trữ một file build.xml đơn giản, trong thư mục gốc của thư mục dự án của bạn:

<project name="my project" default="build"> 

    <include file="C:\vc-tools\shadow\common-build-1.0.xml" as="common"/> 

    <target name="build" depends="common.build"/> 

</project> 

Ghi chú:

  • Bạn nên sử dụng số sửa đổi trong tên tệp xây dựng chung.Điều này giúp duy trì tính tương thích ngược với các bản dựng khác bằng cách sử dụng logic cũ hơn.

Cập nhật

Khi Jenkins đang điều hành một công việc là thiết lập một số environment variables.

Logic ANT sau sẽ in vị trí của thư mục workspace Jenkins:

<property environment="env"/> 

<target name="run"> 
    <echo message="Jenkins workspace: ${env.WORKSPACE}"/> 
    <echo message="Job directory: ${env.WORKSPACE}../../jobs/${env.JOB_NAME}"/> 
    <echo message="Build data: ${env.WORKSPACE}../../jobs/${env.JOB_NAME}/build/${env.BUILD_ID}"/> 
</target> 
+0

điều này có vẻ như nó sẽ rất hữu ích. thực sự, nó đang tạo ra một số lợi thế bổ sung ngoài phạm vi của câu hỏi ban đầu của tôi - cảm ơn cho tip! Tôi sẽ chấp nhận điều này như là câu trả lời khi tôi có cơ hội để kiểm tra rằng nó làm những gì tôi dự đoán sẽ (câu hỏi duy nhất tôi có là $ {basedir} hoặc $ {user.dir} sẽ bằng $ {env.WORKSPACE} hoặc thư mục 'xây dựng' thực sự mà Jenkins đã thiết lập) ... – rguilbault

+0

ok, vì vậy tôi vẫn không thể tham chiếu đến thư mục xây dựng, nhưng hiện tại tôi không cần phải tham khảo nó (nó chứa thông tin về xây dựng mà Jenkins quan tâm, nó không cần phải là mục tiêu cho dự án xây dựng của tôi). nói rằng, sẽ thuận tiện khi sử dụng như một khu vực dàn dựng (phạm vi đầy đủ của những gì tôi cần làm, vì lý do kế thừa, là kiểm tra/cập nhật không gian làm việc từ SVN, tìm kiếm các tệp đã thay đổi gần đây và gọi một người dịch chống lại chúng các tệp đối tượng - các tệp nguồn và đối tượng kết quả sau đó cần được chuyển đến một vị trí có thể truy cập SMB). – rguilbault

+0

... vị trí không gian làm việc là nơi thanh toán/cập nhật đang diễn ra, vì vậy tôi không muốn sully nó với dàn các tập tin (trong đó, btw, tôi quên đề cập đến tôi cần phải đặt trong một cấu trúc cây khác nhau từ cách họ nằm trong điều khiển nguồn). Tôi có thể tạo ra một hệ thống phân cấp độc lập (và tôi có thể) như E: \ staging \ $ {env.BUILD_TAG}, mặc dù Jenkins sẽ không tự động dọn dẹp nó cho tôi, giống như nó sẽ xây dựng thư mục mà nó quản lý (tôi đã hy vọng tạo ra một thư mục con .staging trong đó, mang lại cho tôi trở lại câu hỏi ban đầu của tôi/bài). – rguilbault

5

Những ngày này (. Jenkins v 1,484) mục tiêu 'chạy' từ câu trả lời ở trên sẽ giống như thế này:

<target name="run"> 
    <echo message="Jenkins workspace: ${env.WORKSPACE}"/> 
    <echo message="Job directory: ${env.WORKSPACE}/../../${env.JOB_NAME}"/> 
    <echo message="Build data: ${env.WORKSPACE}/../../${env.JOB_NAME}/builds/${env.BUILD_ID}"/> 
</target> 
Các vấn đề liên quan