Tích hợp liên tục khá tốt cho Python

Đây là một câu hỏi hơi vô ích, nhưng đầu ra của BuildBot không đặc biệt tốt để xem ..

Ví dụ, so với ..

• phpUnderControl
• Jenkins
  • Hudson
• CruiseControl.rb

.. và những người khác, BuildBot trông khá .. cổ xưa

Tôi hiện đang chơi với Hudson, nhưng nó rất tập trung vào Java (mặc dù với hướng dẫn này , tôi thấy việc cài đặt dễ dàng hơn BuildBot và tạo ra nhiều thông tin hơn)

Về cơ bản: có bất kỳ hệ thống Tích hợp liên tục nào nhắm vào python, tạo ra nhiều biểu đồ sáng bóng và lượt thích không?

Cập nhật: Kể từ thời điểm này, dự án Jenkins đã thay thế Hudson thành phiên bản cộng đồng của gói. Các tác giả ban đầu đã chuyển đến dự án này là tốt. Jenkins hiện là gói tiêu chuẩn trên Ubuntu / Debian, RedHat / Fedora / CentOS và các gói khác. Bản cập nhật sau đây về cơ bản vẫn đúng. Điểm khởi đầu để làm điều này với Jenkins là khác nhau.

Cập nhật: Sau khi thử một vài lựa chọn thay thế, tôi nghĩ rằng tôi sẽ gắn bó với Hudson. Liêm chính là tốt đẹp và đơn giản, nhưng khá hạn chế. Tôi nghĩ Buildbot phù hợp hơn với việc có nhiều nô lệ xây dựng, hơn là mọi thứ chạy trên một máy như tôi đang sử dụng.

Thiết lập Hudson cho một dự án Python khá đơn giản:

• Tải xuống Hudson từ http://hudson-ci.org/
• Chạy nó với java -jar hudson.war
• Mở giao diện web trên địa chỉ mặc định của http://localhost:8080
• Chuyển đến Manage Hudson, Plugins, nhấp vào "Cập nhật" hoặc tương tự
• Cài đặt plugin Git (Tôi phải đặt gitđường dẫn trong tùy chọn toàn cầu Hudson)
• Tạo một dự án mới, nhập kho lưu trữ, các khoảng thời gian bỏ phiếu SCM, v.v.
• Cài đặt nosetestsqua easy_installnếu nó chưa có
• Trong bước xây dựng, thêm nosetests --with-xunit --verbose
• Kiểm tra "Xuất bản báo cáo kết quả kiểm tra JUnit" và đặt "XML báo cáo thử nghiệm" thành **/nosetests.xml

Đó là tất cả những gì cần thiết. Bạn có thể thiết lập thông báo email và các plugin đáng để xem. Một số tôi hiện đang sử dụng cho các dự án Python:

• Plugin SLOCCount để đếm các dòng mã (và vẽ biểu đồ đó!) - bạn cần cài đặt sloccount riêng
• Vi phạm để phân tích đầu ra PyLint (bạn có thể thiết lập ngưỡng cảnh báo, vẽ biểu đồ số lượng vi phạm trên mỗi bản dựng)
• Cobertura có thể phân tích cú pháp đầu ra vùng phủ sóng. Nosetest có thể thu thập phạm vi bảo hiểm trong khi chạy thử nghiệm của bạn, bằng cách sử dụng nosetests --with-coverage(điều này ghi đầu ra vào **/coverage.xml)

Bạn có thể muốn kiểm tra plugin đầu ra Mũi và Xunit . Bạn có thể yêu cầu nó chạy thử nghiệm đơn vị của bạn và kiểm tra phạm vi bảo hiểm bằng lệnh này:

nosetests --with-xunit --enable-cover

Điều đó sẽ hữu ích nếu bạn muốn đi theo lộ trình Jenkins hoặc nếu bạn muốn sử dụng một máy chủ CI khác có hỗ trợ báo cáo kiểm tra JUnit.

Tương tự, bạn có thể nắm bắt đầu ra của pylint bằng cách sử dụng plugin vi phạm cho Jenkins

Không biết có làm được không: Bitten được tạo ra bởi những người viết Trac và được tích hợp với Trac. Apache Gump là công cụ CI được sử dụng bởi Apache. Nó được viết bằng Python.

Chúng tôi đã thành công lớn với TeamCity là máy chủ CI của chúng tôi và sử dụng mũi làm người chạy thử nghiệm của chúng tôi. Plugin Teamcity cho nosetests cung cấp cho bạn số lần vượt qua / thất bại, hiển thị có thể đọc được để kiểm tra không thành công (có thể là Email). Bạn thậm chí có thể thấy chi tiết về các lỗi kiểm tra trong khi bạn đang chạy.

Nếu tất nhiên hỗ trợ những thứ như chạy trên nhiều máy, và việc cài đặt và bảo trì sẽ đơn giản hơn nhiều so với buildbot.

Trang thác nước của Buildbot có thể được cải tiến đáng kể. Đây là một ví dụ hay http://build.chromium.org/buildbot/waterfall/waterfall

Tre của Atlassian chắc chắn cũng đáng để kiểm tra. Toàn bộ bộ Atlassian (JIRA, Confluence, FishEye, v.v.) khá ngọt ngào.

Tôi đoán chủ đề này khá cũ nhưng đây là ý kiến ​​của tôi với hudson:

Tôi quyết định đi với pip và thiết lập một repo (đau đớn để làm việc nhưng trông rất đẹp mắt), mà hudson tự động tải lên để thử nghiệm thành công. Đây là tập lệnh thô và sẵn sàng của tôi để sử dụng với tập lệnh thực thi cấu hình hudson như: /var/lib/hudson/venv/main/bin/hudson_script.py -w $ WORKSPACE -p my.package -v $ BUILD_NUMBER, chỉ cần đưa vào ** / cover.xml, pylint.txt và nosetests.xml trong các bit cấu hình:

#!/var/lib/hudson/venv/main/bin/python
import os
import re
import subprocess
import logging
import optparse

logging.basicConfig(level=logging.INFO,
                    format='%(asctime)s %(levelname)s %(message)s')

#venvDir = "/var/lib/hudson/venv/main/bin/"

UPLOAD_REPO = "http://ldndev01:3442"

def call_command(command, cwd, ignore_error_code=False):
    try:
        logging.info("Running: %s" % command)
        status = subprocess.call(command, cwd=cwd, shell=True)
        if not ignore_error_code and status != 0:
            raise Exception("Last command failed")

        return status

    except:
        logging.exception("Could not run command %s" % command)
        raise

def main():
    usage = "usage: %prog [options]"
    parser = optparse.OptionParser(usage)
    parser.add_option("-w", "--workspace", dest="workspace",
                      help="workspace folder for the job")
    parser.add_option("-p", "--package", dest="package",
                      help="the package name i.e., back_office.reconciler")
    parser.add_option("-v", "--build_number", dest="build_number",
                      help="the build number, which will get put at the end of the package version")
    options, args = parser.parse_args()

    if not options.workspace or not options.package:
        raise Exception("Need both args, do --help for info")

    venvDir = options.package + "_venv/"

    #find out if venv is there
    if not os.path.exists(venvDir):
        #make it
        call_command("virtualenv %s --no-site-packages" % venvDir,
                     options.workspace)

    #install the venv/make sure its there plus install the local package
    call_command("%sbin/pip install -e ./ --extra-index %s" % (venvDir, UPLOAD_REPO),
                 options.workspace)

    #make sure pylint, nose and coverage are installed
    call_command("%sbin/pip install nose pylint coverage epydoc" % venvDir,
                 options.workspace)

    #make sure we have an __init__.py
    #this shouldn't be needed if the packages are set up correctly
    #modules = options.package.split(".")
    #if len(modules) > 1: 
    #    call_command("touch '%s/__init__.py'" % modules[0], 
    #                 options.workspace)
    #do the nosetests
    test_status = call_command("%sbin/nosetests %s --with-xunit --with-coverage --cover-package %s --cover-erase" % (venvDir,
                                                                                     options.package.replace(".", "/"),
                                                                                     options.package),
                 options.workspace, True)
    #produce coverage report -i for ignore weird missing file errors
    call_command("%sbin/coverage xml -i" % venvDir,
                 options.workspace)
    #move it so that the code coverage plugin can find it
    call_command("mv coverage.xml %s" % (options.package.replace(".", "/")),
                 options.workspace)
    #run pylint
    call_command("%sbin/pylint --rcfile ~/pylint.rc -f parseable %s > pylint.txt" % (venvDir, 
                                                                                     options.package),
                 options.workspace, True)

    #remove old dists so we only have the newest at the end
    call_command("rm -rfv %s" % (options.workspace + "/dist"),
                 options.workspace)

    #if the build passes upload the result to the egg_basket
    if test_status == 0:
        logging.info("Success - uploading egg")
        upload_bit = "upload -r %s/upload" % UPLOAD_REPO
    else:
        logging.info("Failure - not uploading egg")
        upload_bit = ""

    #create egg
    call_command("%sbin/python setup.py egg_info --tag-build=.0.%s --tag-svn-revision --tag-date sdist %s" % (venvDir,
                                                                                                              options.build_number,
                                                                                                              upload_bit),
                 options.workspace)

    call_command("%sbin/epydoc --html --graph all %s" % (venvDir, options.package),
                 options.workspace)

    logging.info("Complete")

if __name__ == "__main__":
    main()

Khi nói đến việc triển khai công cụ, bạn có thể làm một cái gì đó như:

pip -E /location/of/my/venv/ install my_package==X.Y.Z --extra-index http://my_repo

Và sau đó mọi người có thể phát triển công cụ bằng cách sử dụng:

pip -E /location/of/my/venv/ install -e ./ --extra-index http://my_repo

Công cụ này giả định rằng bạn có cấu trúc repo trên mỗi gói với setup.py và tất cả các phụ thuộc được thiết lập sau đó bạn chỉ cần kiểm tra trung kế và chạy công cụ này trên đó.

Tôi hy vọng điều này sẽ giúp ai đó.

------ cập nhật ---------

Tôi đã thêm epydoc rất phù hợp với hudson. Chỉ cần thêm javadoc vào cấu hình của bạn với thư mục html

Lưu ý rằng pip không hỗ trợ cờ -E đúng cách trong những ngày này, vì vậy bạn phải tạo riêng venv của mình

một số khác: Shining Panda là một công cụ được lưu trữ cho python

Nếu bạn đang xem xét giải pháp CI được lưu trữ và thực hiện mã nguồn mở, bạn cũng nên xem xét Travis CI - nó có tích hợp rất tốt với GitHub. Mặc dù nó bắt đầu như một công cụ Ruby, nhưng họ đã thêm hỗ trợ Python một thời gian trước đây.

Tín hiệu là một lựa chọn khác. Bạn có thể biết thêm về nó và xem một video cũng ở đây .

Tôi sẽ xem xét CircleCi - nó có hỗ trợ Python tuyệt vời và đầu ra rất đẹp.

Bây giờ binstar của continuum có thể kích hoạt các bản dựng từ github và có thể biên dịch cho linux, osx và windows ( 32/64 ). điều gọn gàng là nó thực sự cho phép bạn kết hợp chặt chẽ phân phối và tích hợp liên tục. Đó là vượt qua t và chấm điểm I của hội nhập. Trang web, quy trình làm việc và các công cụ thực sự được đánh bóng và conda AFAIK là cách mạnh mẽ và mạnh mẽ nhất để phân phối các mô-đun python phức tạp, nơi bạn cần bọc và phân phối các thư viện C / C ++ / Fotran.

Chúng tôi đã sử dụng cắn khá nhiều. Nó là đẹp và tích hợp tốt với Trac, nhưng nó là một nỗi đau ở mông để tùy chỉnh nếu bạn có bất kỳ quy trình làm việc không chuẩn. Ngoài ra, không có nhiều plugin như các công cụ phổ biến hơn. Hiện tại chúng tôi đang đánh giá Hudson như một sự thay thế.

Kiểm tra rultor.com . Như bài viết này giải thích, nó sử dụng Docker cho mọi bản dựng. Nhờ đó, bạn có thể định cấu hình bất cứ thứ gì bạn thích bên trong hình ảnh Docker của bạn, bao gồm cả Python.

Từ chối trách nhiệm nhỏ, tôi thực sự đã phải xây dựng một giải pháp như thế này cho một khách hàng muốn có cách tự động kiểm tra và triển khai bất kỳ mã nào trên git đẩy cộng với quản lý vé phát hành thông qua ghi chú git. Điều này cũng dẫn đến công việc của tôi trong dự án AIMS .

Người ta có thể dễ dàng chỉ cần thiết lập một hệ thống nút trần có một người sử dụng xây dựng và quản lý xây dựng của họ thông qua make(1), expect(1), crontab(1)/ systemd.unit(5), và incrontab(1). Người ta thậm chí có thể tiến thêm một bước và sử dụng ansible và cần tây cho các bản dựng phân tán với kho lưu trữ tệp Gridfs / nfs.

Mặc dù, tôi sẽ không mong đợi bất kỳ ai khác ngoài một anh chàng Graybeard UNIX hoặc kỹ sư / kiến ​​trúc sư cấp độ Nguyên tắc thực sự đi xa đến thế này. Chỉ cần tạo ra một ý tưởng hay và trải nghiệm học tập tiềm năng vì một máy chủ xây dựng không gì khác hơn là một cách tự ý thực hiện các nhiệm vụ theo kịch bản theo cách tự động.