Integrasi Berkelanjutan “Pretty” untuk Python

116

Ini pertanyaan yang sedikit .. sia-sia, tetapi keluaran BuildBot tidak terlalu bagus untuk dilihat ..

Misalnya, dibandingkan dengan ..

..dan lainnya, BuildBot terlihat agak .. kuno

Saat ini saya bermain dengan Hudson, tetapi sangat Java-sentris (meskipun dengan panduan ini , saya merasa lebih mudah untuk mengatur daripada BuildBot, dan menghasilkan lebih banyak info)

Pada dasarnya: apakah ada sistem Integrasi Berkelanjutan yang ditujukan untuk python, yang menghasilkan banyak grafik mengkilap dan sejenisnya?


Pembaruan: Sejak saat ini proyek Jenkins telah menggantikan Hudson sebagai versi komunitas dari paket tersebut. Penulis asli telah pindah ke proyek ini juga. Jenkins sekarang menjadi paket standar di Ubuntu / Debian, RedHat / Fedora / CentOS, dan lainnya. Pembaruan berikut pada dasarnya masih benar. Titik awal untuk melakukan ini dengan Jenkins berbeda.

Pembaruan: Setelah mencoba beberapa alternatif, saya pikir saya akan tetap menggunakan Hudson. Integritas bagus dan sederhana, tetapi sangat terbatas. Saya pikir Buildbot lebih cocok untuk memiliki banyak build-slave, daripada semuanya berjalan pada satu mesin seperti yang saya gunakan.

Menyiapkan Hudson untuk proyek Python cukup sederhana:

  • Unduh Hudson dari http://hudson-ci.org/
  • Jalankan dengan java -jar hudson.war
  • Buka antarmuka web di alamat default http://localhost:8080
  • Pergi ke Kelola Hudson, Plugin, klik "Perbarui" atau serupa
  • Instal plugin Git (saya harus mengatur gitjalur di preferensi global Hudson)
  • Buat proyek baru, masukkan repositori, interval polling SCM, dan sebagainya
  • Instal nosetestsmelalui easy_installjika belum
  • Di langkah pembuatan, tambahkan nosetests --with-xunit --verbose
  • Centang "Publikasikan laporan hasil pengujian JUnit" dan setel "XML laporan pengujian" ke **/nosetests.xml

Hanya itu yang dibutuhkan. Anda dapat mengatur notifikasi email, dan pluginnya layak untuk dilihat. Beberapa yang saat ini saya gunakan untuk proyek Python:

  • Plugin SLOCCount untuk menghitung baris kode (dan membuat grafik!) - Anda perlu menginstal sloccount secara terpisah
  • Pelanggaran untuk mengurai keluaran PyLint (Anda dapat menyiapkan ambang peringatan, membuat grafik jumlah pelanggaran pada setiap build)
  • Cobertura dapat mengurai output coverage.py. Nosetest dapat mengumpulkan cakupan saat menjalankan pengujian Anda, menggunakan nosetests --with-coverage(ini menulis output ke **/coverage.xml)
dbr
sumber
Pertanyaan bagus, saya sedang melihat hal yang serupa sekarang. Jika Anda menempuh satu cara, dapatkah Anda berbagi pengalaman dengan kami semua?
André
3
Tidak tahu apakah itu tersedia ketika Anda menulis ini: Gunakan plugin Chuck Norris untuk Hudson untuk lebih meningkatkan kontrol atas barang-barang Anda!
Johannes Charra
8
Pembaruan untuk 2011/2012 : Mereka yang mempertimbangkan Hudson harus menggunakan Jenkins , kelanjutan open source dari proyek Hudson (Hudson sekarang dikendalikan oleh Oracle )
mindthief

Jawaban:

41

Anda mungkin ingin memeriksa Nose dan plugin keluaran Xunit . Anda dapat menjalankan pengujian unit Anda, dan pemeriksaan cakupan dengan perintah ini:

nosetests --with-xunit --enable-cover

Itu akan membantu jika Anda ingin menggunakan rute Jenkins, atau jika Anda ingin menggunakan server CI lain yang memiliki dukungan untuk pelaporan pengujian JUnit.

Demikian pula Anda dapat menangkap keluaran pylint menggunakan plugin pelanggaran untuk Jenkins

Jason Baker
sumber
4
Nose sekarang menyertakan plugin xunit secara default -nosetests --with-xunit
dbr
3
Jadi bagaimana cara menjalankan audit dari Pylint? Ketika saya melakukannya, nosetests --with-xunit --enable-auditsaya mendapatkannosetests: error: no such option: --enable-audit
Adam Parkin
2
Jawaban yang dimodernisasi, barang NoseXUnit sekarang dibangun dan diganti namanya dari yang tidak menguntungkan saat diturunkan --with-nosexunitmenjadi --with-xunit.
dbr
10

Tidak tahu apakah itu akan berhasil: Bitten dibuat oleh orang-orang yang menulis Trac dan terintegrasi dengan Trac. Apache Gump adalah alat CI yang digunakan oleh Apache. Itu ditulis dengan Python.

edomaur
sumber
9

Kami telah sukses besar dengan TeamCity sebagai server CI kami dan menggunakan hidung sebagai pelari pengujian kami. Plugin Teamcity untuk nosetests memberi Anda jumlah lulus / gagal, tampilan yang dapat dibaca untuk tes yang gagal (yang dapat dikirim melalui E-Mail). Anda bahkan dapat melihat detail kegagalan pengujian saat stack Anda berjalan.

Jika tentu saja mendukung hal-hal seperti menjalankan beberapa mesin, dan jauh lebih mudah untuk mengatur dan memelihara daripada buildbot.

Kozyarchuk
sumber
6

Atlassian's Bamboo juga patut untuk dicoba. Seluruh paket Atlassian (JIRA, Confluence, FishEye, dll) cukup manis.

Russ
sumber
6

Saya kira utas ini cukup tua tetapi inilah pendapat saya tentang hudson:

Saya memutuskan untuk menggunakan pip dan menyiapkan repo (yang menyakitkan untuk bekerja tetapi eggbasket terlihat bagus), yang diunggah secara otomatis oleh hudson dengan tes yang berhasil. Berikut ini skrip kasar dan siap saya untuk digunakan dengan skrip eksekusi konfigurasi hudson seperti: /var/lib/hudson/venv/main/bin/hudson_script.py -w $ WORKSPACE -p my.package -v $ BUILD_NUMBER, masukkan saja ** / coverage.xml, pylint.txt dan nosetests.xml di bit konfigurasi:

#!/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()

Dalam hal menerapkan hal-hal, Anda dapat melakukan sesuatu seperti:

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

Dan kemudian orang dapat mengembangkan sesuatu dengan menggunakan:

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

Hal ini mengasumsikan Anda memiliki struktur repo per paket dengan setup.py dan semua dependensi sudah diatur maka Anda dapat memeriksa trunk dan menjalankan hal ini di dalamnya.

Saya harap ini membantu seseorang.

------memperbarui---------

Saya telah menambahkan epydoc yang sangat cocok dengan hudson. Cukup tambahkan javadoc ke konfigurasi Anda dengan folder html

Perhatikan bahwa pip tidak mendukung flag -E dengan benar saat ini, jadi Anda harus membuat venv secara terpisah

Nick Holden
sumber
Jawaban ini sangat berguna dan memiliki banyak detail tentang internal Python CI, sesuatu yang tidak akan Anda dapatkan secara gratis dari Jenkins atau apa pun. Terima kasih!
maksimov
3

Jika Anda sedang mempertimbangkan solusi CI yang dihosting, dan menggunakan sumber terbuka, Anda juga harus melihat Travis CI - ini memiliki integrasi yang sangat bagus dengan GitHub. Saat ini dimulai sebagai alat Ruby, mereka telah menambahkan dukungan Python beberapa waktu lalu.

Alex Dupuy
sumber
2

Sinyal adalah pilihan lain. Anda dapat mengetahui lebih banyak tentang itu dan menonton video juga di sini .

Diego Carrion
sumber
2

Saya akan mempertimbangkan CircleCi - ia memiliki dukungan Python yang hebat, dan hasil yang sangat bagus.

Paul Biggar
sumber
1

Continum 's binstar sekarang dapat memicu build dari github dan dapat dikompilasi untuk linux, osx dan windows ( 32/64 ). hal yang menarik adalah itu benar-benar memungkinkan Anda untuk menggabungkan distribusi dan integrasi berkelanjutan. Itu melintasi t dan menghiasi I Integrasi. Situs, alur kerja, dan alat benar-benar dipoles dan AFAIK conda adalah cara paling kuat dan pythonic untuk mendistribusikan modul python yang kompleks, di mana Anda perlu membungkus dan mendistribusikan pustaka C / C ++ / Fotran.

Jelle
sumber
0

Kami telah menggunakan gigitan cukup banyak. Ini cantik dan terintegrasi dengan baik dengan Trac, tetapi sulit untuk menyesuaikan jika Anda memiliki alur kerja yang tidak standar. Juga tidak ada banyak plugin seperti yang ada untuk alat yang lebih populer. Saat ini kami sedang mengevaluasi Hudson sebagai penggantinya.

Allen
sumber
0

Periksa rultor.com . Seperti yang dijelaskan artikel ini , ini menggunakan Docker untuk setiap build. Berkat itu, Anda dapat mengonfigurasi apa pun yang Anda suka di dalam gambar Docker Anda, termasuk Python.

yegor256
sumber
0

Sedikit penafian, saya sebenarnya harus membuat solusi seperti ini untuk klien yang menginginkan cara untuk secara otomatis menguji dan menerapkan kode apa pun pada git push plus mengelola tiket masalah melalui catatan git. Ini juga mengarah pada pekerjaan saya di proyek AIMS .

Satu bisa dengan mudah hanya setup sistem simpul telanjang yang memiliki build pengguna dan mengelola membangun mereka melalui make(1), expect(1), crontab(1)/ systemd.unit(5), dan incrontab(1). Seseorang bahkan dapat melangkah lebih jauh dan menggunakan ansible dan seledri untuk build terdistribusi dengan penyimpanan file gridfs / nfs.

Meskipun, saya tidak akan mengharapkan orang lain selain seorang pria Graybeard UNIX atau insinyur / arsitek tingkat Principle untuk benar-benar melangkah sejauh ini. Hanya membuat ide bagus dan pengalaman belajar potensial karena server build tidak lebih dari cara untuk secara sewenang-wenang menjalankan tugas-tugas skrip secara otomatis.

Dwight Spencer
sumber