はじめに 今回は、Jenkins と Python の連携についてです。 使用するツールは、とても便利なテストフレームワーク nose と カバレッジ coverage との連携についてです。 nose連携 まず、 nose との連携からです。 nose をそのまま実行したのでは、Jenkinsに取り込めないため、XUnit形式のレポートを出力する必要があります。 XUnit形式のレポート出力には、 unittest-xml-reporting を導入する必要があります。 unittest-xml-reporting がインストールされていると、noseの出力レポートをXUnit形式にすることができます。 インストール $ easy_install -ZU nose $ easy_install -ZU unittest-xml-reportingnose の使い方は割愛しますが、コマンド
練習がてら、 Hudson のプラグインを書いてみました。 Play むけのプラグインなんて、ほとんど需要無さそうですが、Hudson の ML に投げたら受け入れてもらえたりするんでしょうか?? とりあえず、コードは下記に置いてあります。 https://github.com/ikeike443/HudsonPluginForPlay 出来ること Play auto-test コマンドを実行できます テスト結果を Calimoucho 風*1に閲覧することが出来ます 使い方 プラグインをインストールしたら*2、「Hudsonの管理>システム設定」の下記箇所に Play スクリプトの格納場所を記述します。 次に、「新規ジョブ作成>フリースタイルプロジェクト」でジョブを作成し、下記2箇所を設定します。 1.「ビルド手順の追加」で 「Play!」を選択し、"auto-test" と設定します。
■ [ruby][hudson][rvm][gentoo] Gentoo + rvm + hudson で CI サーバーを作った tDiary は 1.8.7 と 1.9.2 のサポートをしていると言ってるわりには両方の環境でかっちりとテストを実行していたりするわけではないので、rvm と hudson でかっちりとテストを実行するようにしてみた。 そんなわけで出来たのがこれ → http://ci.hsbt.org わりとはまった箇所があるのでメモしておくよ。 Gentoo に hudson を入れる godin というレポジトリにgentoo用の hudson があるのでそれを使った。これは layman を使うことにした。 http://code.google.com/p/godin-gentoo-repository/wiki/HowTo 上記の手順にしたがって、layman.c
Hudson PXE plugin が Windows で動かなかったことは前にちらっと書きましたが。とりあえず PXE サーバが立てたかったので VMware 上の CentOS 5.5 に Hudson を入れて動かしてみました。 結構色々ハマったので、まずは PXE サーバを起動するまでのところを書いておきます。 Hudson 1.384、Hudson PXE netboot plugin 1.5 で検証してます。 動機 社内のサーバをもろもろ整理中なんですが、状況としては、 Hudson PXE plugin - 川口耕介の日記 インストールには通常メディアの入ったCD-ROMが必要ですし、PC側にはドライブも必要です(そして、なぜか使い古しのPCはCD-ROMドライブが不安定なものが多いのです。)そして、往々にして、CDはどこかのドライブに入れ忘れたまま、ということになります。
Performance Pluginを使えばant+jmeterで簡単に出来る。jmeter-maven-pluginなんてものもあるけれど負荷テストをプロジェクトのpomに書くのはやり過ぎ感にあふれるので今回は使わなかった。 まずはantを使って負荷テスト用プロジェクトを以下のようなディレクトリ構成で作成。ぶっちゃけPerformance Pluginのwikiのをコピーしてディレクトリをちょこっと弄るだけで済んだ。わーい。 load-test ├── build.xml ├── results:結果ファイル用ディレクトリ │ ├── html │ └── jtl └── scenarios:jmxファイル置き場 ├── some-dynamic-properties.csv └── some-stress.jmxbuild.xml <project default="all"> <pr
hudson, rails前々から興味があったhudsonをrails3のアプリケーションで使ってみた。rvmを利用して綺麗な環境でビルドすることが目標。 hudsonの起動第1回 Hudsonの導入|gihyo.jp … 技術評論社を参考にしました。すんなり動くかと思いきや、HTTPサーバが起動しない。しかもエラーも吐かないものだから困った。 原因を調べるとhudsonが悪いワケじゃなかった。winstoneの中でIPv6のlocalhostにconnectしているところでシーンという感じ。ip6tablesを見るとloが空いてなくて、パケットがことごとく捨てられてたみたい。 ping6 ::1 すら何も帰ってこなかった…。タイムアウトに時間がかかるのでエラーが吐かれる前に手で止めてて、エラーが確認できなかったのです。しくしく。 とりあえず、IPv4を優先的に使うようにする。 $ jav
仕事では30-40ノード位のHudsonクラスタを運用しているのですが、常々、このクラスタをもっと多用途に使えたら便利だと思っていました。 HadoopをHadoop推奨の方法でインストールしてもよいのですが、ネットワークの情報等をHudsonとHadoopに別々に教えないといけないのは不便です。そこで、週末を2つ使って、HudsonクラスタにHadoopを展開するためのプラグインを書きました。Hadoopのコードを読むのに少し手間取りましたが、一度肝を掴んでからは比較的簡単でした。 このプラグインをインストールすると、Hudsonのクラスタ全域でHadoopノードが実行され、またネットワークの設定に関する情報が自動的にHudsonからHadoopへ伝えられます。ユーザーは、HadoopプラグインをHudsonにインストールする以外にはやることはなにもありません。いわゆる「zero con
こんな感じでhudsonに表示される。 手順は以下。自分用のメモなので雑です! バッチファイルを作って、hudsonから叩く。 過去の結果があれば削除 del MsTestSample\TestResults\TestResults.trx rmdir /S /Q MsTestSample\TestResults\TestResult テスト実行 "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe" /runconfig:MsTestSample\LocalTestRun.testrunconfig /testcontainer:MsTestSample\TestMsTestSample\bin\Debug\TestMsTestSample.dll /resultsfile:MsTestSample\Te
12月5 UbuntuでHudsonをパッケージ管理する カテゴリ:My ComputerMy Java ちらっとHudsonのページを見に行ったら、UNIX系OS向けにパッケージ管理できるようになってました。 試しにVMWare上のUbuntuに入れてみました。 以下メモメモ。 まずはコンソールでwget -O - http://hudson-ci.org/debian/hudson-ci.org.key | sudo apt-key add - --10:53:37-- http://hudson-ci.org/debian/hudson-ci.org.key => `-' hudson-ci.org をDNSに問いあわせています... 192.18.49.133 hudson-ci.org|192.18.49.133|:80 に接続しています... 接続しました。 HTTP による接
C言語プロジェクトもHudsonでビルドしてみよう(゚д゚)/ まずは環境構築 Slave端末にC言語実行環境とユニットテスト環境をインストールします。 ・gcc ・CUnit2.1.0 Makefileを用意します。 make clean ディレクトリの掃除 make コンパイル make run ユニットテスト実行 PACKAGE = test SRCS = $(PACKAGE).c OBJS = $(SRCS:.c=.o) CC = gcc CFLAGS = -L/usr/local/lib -lcunit all: $(PACKAGE) .c.o: $(CC) $(CFLAGS) -c $< -o $@ ### useful commands ### clean: $(RM) $(PACKAGE) $(OBJS) $(RM) core *.xml run: ./$(PACKAGE)
Reprocessed, by Matt Patterson Something approaching a weblog RecentlyThe archivesTags For a long time I've thought that it would be a good idea to have a Continuous Integration server that could run all the tests for a project on checkin to source control. Until I started making use of Cucumber I didn't really have a full test run that took long enough to make buying a separate CI server feel mor
Recently I was working on a refactor of one of my CPAN modules which, among other things, involved changing its name from Test::A8N to the specific Test::Story. Doing so made me think about the process I usually go through when I consider releasing a CPAN module. First, let me explain something about myself: I don’t like tedious or repetitive tasks. I hate having to do the same thing over and ov
Hudson supports the "master/slave" mode, where the workload of building projects are delegated to multiple "slave" nodes, allowing single Hudson installation to host a large number of projects, or provide different environments needed for builds/tests. This document describes this mode and how to use it. Contents How does this work? A "master" is an installation of Hudson. When you weren't using t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く