はじめに 「誰かがジョブの設定を誤って変更してしまったため、昨日まで問題なく動いていた自動ビルドが失敗してしまい、問題の特定に時間がかかってしまった」なんてことになると面倒です。 このような場合、「過去の設定」と「現在の設定」が簡便に比較できるようになっていると、問題点を短時間で特定できて助かります。 そこで、この記事では、このような状況の改善策の一手段としてJobConfigHistoryプラグインを紹介したいと思います。 なお、このプラグインは簡潔に述べると、 いつ 誰が 何の設定を どのように変更したのか を調査するための機能を提供します。 インストール JobConfigHistory Pluginの名称と関連URLは次のとおりです。 プラグイン名 Wiki URL ダウンロード URL GitHub URL JobConfigHistory Plugin http://wiki.
はじめに Hudsonを標準状態のままで使用した場合、Hudsonにアクセスできる全てのユーザが、Hudsonの全ての機能を制限なく利用できてしまいます。 Hudsonの機能を熟知しているチーム内でHudsonを使用するのであれば、この標準状態の方が設定に煩わされない分、簡便に運用できるので都合が良いかもしれません。 しかし一般的には、間違った操作によってHudsonが動作しなくなることを防ぐために、「Hudsonの管理者」と「Hudsonの利用者」くらいの最低限の区別をした方が良いのではないかと思います。 そこで、この記事では、Hudsonのユーザーデータベースを使用して、Hudsonの操作権限を制御する方法について説明したいと思います。 なお、説明を簡素化するために、Hudsonの公式サイトにはない用語や分類を用いて説明していますので、その点はご了承ください。 操作権限を制御する前に
http://weblogs.java.net/blog/johnsmart/archive/2010/11/21/hudson-build-jobs-build-pipelines-0 Continuous Integration with Hudson本の作者であるJohn Ferguson Smartさんのスライド（と言ってもHudson本はまだ出てないよ）。 いろいろプラグインが紹介されてて興味深い。以下、紹介されてたやつで知らなかったヤツを列挙。機会があれば試してみる。 ■Dashboard Nested View plugin この前のHudson勉強会で紹介されてたのはDashboard View。スクリーンショットないけど説明文読む限りではジョブをグループ化してフォルダにまとめてくれるようだ。 ■HTML Publisher plugin ジョブ中（ジョブのワークスペース上
日本人(http://twitter.com/kohsukekawa)がリードする継続的インテグレーションツール(http://ja.wikipedia.org/wiki/Hudson)の開発コミュニティーとオラクルの間に摩擦が生じている。 http://www.hudson-labs.org/content/whos-driving-thing バックグラウンド： Hudsonはフリーソフトウエア(MIT License)だが、Kohsuke KawaguchiさんがSunにいたころ開発されたため、同社がプロジェクトのトレードマークを持っていたらしい。 買収によりSunのHudsonにたいする権利もオラクルのものになった。 元記事に詳しいタイムラインがあるが、肝心なところを拾うと： 開発はjava.netでホスティングされていたが信頼性の問題などからメーリングリストはgoogle gro
先週、redmineなどを入れたサーバにHudsonも入れてみたので手順を書いておきます。バージョンは以下のとおり。CentOS : 5.5JDK : 1.6.0_21Hudson : 1.367javaのアンインストール素のCentOSではJDKは入ってないと思われますので、インストールする必要がありますが、そのまえにすでに入っているjavaをアンインストールします。 yum erase java JDKのインストール1. JDKのダウンロードページでLinuxを選択して、Downloadボタンをクリックします。2. 遷移左記の画面で"jdk-6u21-linux-i586-rpm.bin"のリンクのアドレスをコピーします。3. CentOSにログインして以下を実行します。 cd /tmp wget -O jdk-6u21-linux-i586-rpm.bin "手順2でコピーしたアドレ
Extend Hudson Learn how to build Hudson or extend Hudson by writing plugins. 02/15/2016 - Hudson 3.3.3 Security Patch Released Hudson 3.3.3 is now available from the Hudson downloads page. This is a patch set improves the default security of Hudson by locking down the Hudson Command Line Interface (CLI) by default. For more information see the changelog 11/02/2015 - Hudson 3.3.2 Security Patch Rel
実験用としてHudson（1.326）のRPM化がなされたため、RedHat系のLinuxでパッケージ管理を行うことできるようになりました。 早速試したところ、CentOS5.2にて特に問題なく動作を確認できました。 以下、yumでインストールした手順を紹介します。 まず、公開鍵をインポートします。 rpm --import http://hudson-ci.org/redhat/hudson-ci.org.key 次に、/etc/yum.repos.d/CentOS-Base.repoをエディタで開き、以下のを文を追記します。 #Hudson [hudson] name= Hudson baseurl=http://hudson-ci.org/redhat/ enabled=0 gpgcheck=1 gpgkey=http://hudson-ci.org/redhat/hudson-ci
Hudsonプラグイン開発について調べたことを書いてみたいと思います。環境は下記の通りです。 OS Vista JDK 1.6 Maven 2.0.10 http://wiki.hudson-ci.org/display/HUDSON/Plugin+tutorialにしたがってやってみます。このプラグインはビルド実行するとhelloと出力します。 %USERPROFILE%\.m2\settings.xmlを下記のように記述します。 <settings> <profiles> <profile> <id>hudson</id> <activation> <activeByDefault /> </activation> <pluginRepositories> <pluginRepository> <id>m.g.o-public</id> <url>http://maven.glassf
[TS-5301]Continuous Integration in the Cloud with Hudson http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5301&yr=2009 Hudsonをクラウドで使うためにやった工夫などを紹介するセッション。 前提知識として、↓のエントリの内容を押さえておくと良い。 主な観点は3つ。 1. プロビジョニングの方法、要するに「OSやミドルのデータや設定情報」を、どう管理するか。 2. モニタリングの方法。性能や障害情報を、どう監視するか。 3. リソースの管理方法。リソースといってもCPUやメモリじゃなくて、IPアドレスやマシンIDなど。 クラウドコンピューティングのパターン。 - せろ部屋 HudsonのMasterやSlaveをクラウド（Amazo
仕事では30-40ノード位のHudsonクラスタを運用しているのですが、常々、このクラスタをもっと多用途に使えたら便利だと思っていました。 HadoopをHadoop推奨の方法でインストールしてもよいのですが、ネットワークの情報等をHudsonとHadoopに別々に教えないといけないのは不便です。そこで、週末を２つ使って、HudsonクラスタにHadoopを展開するためのプラグインを書きました。Hadoopのコードを読むのに少し手間取りましたが、一度肝を掴んでからは比較的簡単でした。 このプラグインをインストールすると、Hudsonのクラスタ全域でHadoopノードが実行され、またネットワークの設定に関する情報が自動的にHudsonからHadoopへ伝えられます。ユーザーは、HadoopプラグインをHudsonにインストールする以外にはやることはなにもありません。いわゆる「zero con
前回のおまけです。 自分でLive-USB作るの面倒という方は、こちらをダウンロードしてください。300MB位あるので気長にダウンロードしてください。回線マジで細いから。 展開する bootとslaxディレクトリをUSBにコピー cd boot sh bootinst.sh で終わりです。容量でかいのでkofficeを削除してます。また、ブート時の画面をHudson氏の画像に差し替えています。 あと、書き忘れましたが、クライアントにはMavenやAntは入っていません。Hudson 1.310?ぐらいで追加された/される自動インストール機能が便利です。 では、頭が痛いのでバファリン飲んで寝ます。
続きます。 ここで、USBからブートしてSLAX上で作業します。ブートに成功するとKDEが立ち上がるはずです。 KConsoleを立ち上げて作業します。 Hudsonのアカウントを作る swarmクラインアントを動かすアカウントを作ります。rootでもいいですがとりあえず"hudson"グループの"hudson"というアカウントを作ります。 root@slax:~# addgroup hudson root@slax:~# useradd -g hudson -d /home/hudson -s /bin/bash hudson root@slax:~# mkdir /home/hudson root@slax:~# chown hudson:hudson /home/hudson Swarmクライアントの動作環境を作る /home/hudsonにswarmクライアントを配置し、FSルート
Hudson swarmプラグインを使って、Hudsonのスレーブが起動するLive USBを作ってみようというお話です。 用意するもの ハード USBブートできるPC USB(最低でも512MB、ビルドするプロジェクトによります。今回は8GBを使ってます) DHCPサーバ (追記) ソフト SLAX日本語版 slax-ja-6.1.1-2.iso SLAXのJDKモジュール jdk-6u11-i586-1pst.lzm Huson swarmプラグイン swarm-client-1.0-jar-with-dependencies.jar USBのフォーマット USBをVFATでフォーマットしておきます。最低でも500MBぐらいいります。ビルドもするので1GB以上は必要でしょう。 SLAXのインストール SLAXは、8cmのCD-ROMディスクに収まり、速くて美しいLinuxオペレーティン
この連載では、オープンソースの継続的インテグレーション（CI）サーバであるHudsonを利用した、ソフトウェア開発の生産性向上について解説しています。前回の記事では、Hudson上に継続的ビルドを設定して、ソースコードに加えられた変更をいち早くビルドし、結果を開発者にフィードバックする方法に付いて見てきました。今回は、視野を少し広げて、規模の大きいソフトウェアプロジェクトの開発で、Hudsonを更に有効活用する方法についてみていきます。 テストを有効活用する 実行したテストの結果をHudson上に集計する方法については前回述べました。ビルドと同時にテストもやってしまうという手法は、小さなプロジェクトやライブラリ、もしくはテストの数も少ない場合にはとても有効です。ですが、プロジェクトが大きくなりテストの数が増えるにつれ、テストの実行時間が長くなり、この方法では迅速にフィードバックを得ることが
職場のHudsonクラスタには予算がついていないので、性能の良い計算機を集めるのがなかなか大変です。これは、Hudsonクラスタを作る人たちには共通の悩みではないかと思います。いきおい、同僚の古いコンピューターをリサイクルすることになるのですが、ここに罠があります。 というのも、新しいコンピュータを買った人のところに行って「古くなったコンピュータ、使ってないみたいだからちょうだい」といっても、中々首を縦にふってもらえないのですね。皆さんも経験あると思うのですが、古くなったコンピュータでも、ひょっとしたらまた使うかもしれないし、とか、もしかしたらデータのコピー忘れがあるかもしれないし、と心配になってしまうわけです。あげてしまったコンピュータがフォーマットされてしまう以上、これはもっともな心配です。 そこで、新しい作戦として、コンピュータを貰い受けるのではなくて、単に仮想マシンを走らせてもらう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
