＆＃8220;プリティ＆＃8221; Pythonの継続的統合

StackOverflow https://stackoverflow.com/questions/225598

質問

これは少し..無駄な質問ですが、BuildBotの出力は特に見栄えがよくありません。

たとえば、比較..

..およびその他、 BuildBot はむしろ見えます。古風な

現在、Hudsonで遊んでいますが、非常にJava中心です（ただしこのガイドでは、BuildBotよりもセットアップが簡単であることがわかり、詳細情報を作成しました）

基本的に、多くの光沢のあるグラフなどを生成する、Python向けの継続的インテグレーションシステムはありますか？

更新：今回から、JenkinsプロジェクトがパッケージのコミュニティバージョンとしてHudsonを置き換えました。元の作者もこのプロジェクトに移動しました。 JenkinsはUbuntu / Debian、RedHat / Fedora / CentOSなどの標準パッケージになりました。次の更新は依然として本質的に正しいです。 Jenkins でこれを行う開始点は異なります。

更新： いくつかの代替案を試した後、私はハドソンに固執すると思います。 Integrity は素晴らしくシンプルでしたが、かなり制限されていました。 Buildbot は、私が使用しているような1台のマシンですべてを実行するのではなく、多数のビルドスレーブを持つのに適していると思います。それ。

Pythonプロジェクト用にHudsonを設定するのは非常に簡単でした：

  • http://hudson-ci.org/
    • からHudsonをダウンロードします
  • java -jar hudson.war
    • で実行します
  • デフォルトアドレスの http：// localhost：8080
    • でWebインターフェースを開きます
  • 「Hudson、プラグインの管理」に移動して、「更新」をクリックします。または同様の
  • Gitプラグインをインストールします（Hudsonグローバル設定で git パスを設定する必要がありました）
  • 新しいプロジェクトを作成し、リポジトリ、SCMポーリング間隔などを入力します
  • easy_install で nosetests をインストールします（まだインストールされていない場合）
  • ビルドステップで、 nosetests --with-xunit --verbose
    • を追加します
  • 「JUnitテスト結果レポートを公開」をチェックします。 ＆quot;テストレポートXML＆quot;を設定します。 ** / nosetests.xml
    • へ

これですべてです。メール通知を設定できます。プラグインは一見の価値があります。私が現在Pythonプロジェクトに使用しているもの：

  • SLOCCountプラグインを使用して、コードの行数をカウントします（グラフ化します）。 ）- sloccount を個別にインストールする必要があります
  • 違反 PyLint出力を解析します（警告しきい値、グラフを設定できます各ビルドでの違反の数）
  • Cobertura はcoverage.pyの出力を解析できます。 Nosetestは、テストの実行中に nosetests --with-coverage を使用してカバレッジを収集できます（これにより、出力が ** / coverage.xml に書き込まれます）
役に立ちましたか？

解決

鼻と Xunit出力プラグイン。単体テストを実行して、次のコマンドでカバレッジチェックを実行できます。

nosetests --with-xunit --enable-cover

Jenkinsルートを利用する場合、またはJUnitテストレポートをサポートする別のCIサーバーを使用する場合に役立ちます。

同様に、 Jenkinsの違反プラグインを使用して、pylintの出力をキャプチャできます。

他のヒント

どうなるかわからない： Bitten は、Tracを書いて統合された人たちによって作られていますTracで。 Apache Gump は、Apacheが使用するCIツールです。 Pythonで書かれています。

CIサーバーとして TeamCity を使用し、テストランナーとしてnoseを使用して大成功を収めました。 。 nosetestsのTeamcityプラグインは、失敗したテストの合格/失敗、読み取り可能な表示をカウントします電子メールで送信されます）。スタックの実行中にテストの失敗の詳細を確認することもできます。

もちろん、複数のマシンでの実行などをサポートしている場合、ビルドボットよりもセットアップと保守がはるかに簡単です。

Buildbotのウォーターフォールページはかなりきれいにすることができます。良い例は http://build.chromium.org/buildbot/waterfall/waterfall です。

Atlassianの Bamboo もチェックする価値があります。 Atlassianスイート全体（JIRA、Confluence、FishEyeなど）は非常に甘いです。

このスレッドはかなり古いと思いますが、ハドソンとの私の見解は次のとおりです。

pipを使用してリポジトリを設定することにしました（動作するのは苦痛ですが、見栄えの良い卵バスケット）。テストに成功すると、ハドソンは自動アップロードします。ここに、次のようなhudson config実行スクリプトで使用するための大まかな準備スクリプトを示します。/var/lib/hudson/venv/main/bin/hudson_script.py -w $ WORKSPACE -p my.package -v $ BUILD_NUMBER構成ビットの** / coverage.xml、pylint.txt、nosetests.xml：

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

もののデプロイに関しては、次のようなことができます：

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

そして、人々は以下を使用してものを開発できます：

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

この内容では、パッケージごとにsetup.pyと依存関係がすべて設定されたリポジトリ構造があり、トランクをチェックアウトして実行できることを前提としています。

これが誰かの助けになることを願っています。

------ update ---------

ハドソンと非常にうまく適合するepydocを追加しました。 htmlフォルダーで設定にjavadocを追加するだけです

最近、pipは-Eフラグを適切にサポートしていないため、venvを個別に作成する必要があることに注意してください

もう1つ： Shining Panda は、Python用のホスト型ツールです

ホストされたCIソリューションを検討していて、オープンソースを実行している場合は、 Travis CI を次のように調べる必要があります。まあ-それはGitHubと非常に素晴らしい統合をしています。 Rubyツールとして開始されましたが、 Pythonサポートを追加しました。

Signalは別のオプションです。あなたはそれについてもっと知り、ビデオを見ることができますこちら。

CircleCi を検討します。Pythonサポートが優れており、出力が非常にきれいです。

continuumの binstar は、githubからビルドをトリガーし、 linux、osxおよびwindows（32/64）。すてきなことは、配布と継続的インテグレーションを密接に結合できることです。それはtを超え、統合のIを点けています。サイト、ワークフロー、およびツールは非常に洗練されており、AFAIK condaは複雑なpythonモジュールを配布するための最も堅牢でpythonicな方法です。C/ C ++ / Fotranライブラリを配布する必要があります。

かみ傷をかなり使用しました。それはきれいで、Tracとうまく統合できますが、非標準のワークフローがある場合はカスタマイズするのが面倒です。また、人気のあるツール用のプラグインほど多くはありません。現在、ハドソンを代替品として評価しています。

rultor.com を確認します。 この記事で説明しているように、すべてのビルドにDockerを使用しています。そのおかげで、Pythonなど、Dockerイメージ内で好きなものを設定できます。

小さな免責事項、Gitプッシュで任意のコードを自動的にテストおよび展開し、git noteを介して発行チケットを管理する方法が必要なクライアントに対して、実際にこのようなソリューションを構築する必要がありました。これは、 AIMSプロジェクトでの私の仕事にもつながります。

ビルドユーザーがいるベアノードシステムを簡単にセットアップし、 make（1）、 expect（1）、 crontabでビルドを管理できます。 （1） / systemd.unit（5）、および incrontab（1）。さらに一歩進んで、gridfs / nfsファイルストアを使用した分散ビルドにansibleとceleryを使用することもできます。

とはいえ、Graybeard UNIXやPrincipleレベルのエンジニア/アーキテクト以外の人が実際にここまで行くとは思わないでしょう。ビルドサーバーは、自動化された方法でスクリプト化されたタスクを任意に実行する方法に過ぎないため、素晴らしいアイデアと潜在的な学習体験を提供します。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top